Re: restore whoes - Mailing list pgsql-admin
From | Bruce Momjian |
---|---|
Subject | Re: restore whoes |
Date | |
Msg-id | 200202111531.g1BFVfv11628@candle.pha.pa.us Whole thread Raw |
In response to | Re: restore whoes (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: restore whoes
Re: restore whoes |
List | pgsql-admin |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
pgsql-admin by date: