From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simone Tellini <tellini(at)areabusiness(dot)it>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: restore whoes |
Date: | 2002-02-11 15:31:41 |
Message-ID: | 200202111531.g1BFVfv11628@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I was thinking of throwing a specific error when copy fails _and_ when
> > the line ends with a \r, rather than a generic COPY failure message ---
> > not sure how to do that, though.
>
> Doesn't seem practical, as the actual error may not occur till much
> later, far away from the COPY code itself.
OK, how about if we have a global char * called "extra_elog_output"
which we set before doing a /utils/adt data conversion on the last
column of the first row _if_ it ends in a carriage return. We clear it
once we successfully return. In elog.c, we print any extra string that
may be defined for extra_elog_output. I wonder if we could make use of
this other places.
Also, if we add a WITH TRIMCR option to COPY, we can suggest that in the
error message. We can add ONLYCR for Mac files ending only in \r.
>
> > I don't think I like the carriage-return -> \r solution anymore because
> > that would require people creating COPY files by hand, which I am sure
> > many do, to also escape carriage returns, which seems too MS-ish for me.
>
> We have to change *something*, Bruce, because as things stand it's
> completely ambiguous whether a \r is a legitimate data character or
> something introduced by a newline conversion. If you insist on 100%
> backwards compatibility then we'll be fighting this problem forever.
> (Or at least till Windows dies ... yeah right.)
I think we can live with it _if_ we report a proper error message and
suggest a solution. In fact, in some ways, it may be better to report
and fail rather than silently try to fix it.
> Please note also that \ r (two characters) is *already* accepted as
> meaning a carriage return. Ditto \ 0 1 5. So it's quite possible
> that applications generating COPY data may be using one of these
> representations and not be affected in the slightest.
Yes, I know, and it is obvious to COPY coders they have to escape \n
because that is their end-of-line character, but it is not obvious why
they would escape \r.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Jay Wren | 2002-02-11 15:47:07 | Re: History Keys fault |
Previous Message | Bruce Momjian | 2002-02-11 15:19:23 | Re: pg_upgrade cmdline issue |