From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(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 06:20:30 |
Message-ID: | 2198.1013408430@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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.
> 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.)
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Bertheau | 2002-02-11 08:35:46 | pg_upgrade cmdline issue |
Previous Message | Bruce Momjian | 2002-02-11 06:02:29 | Re: restore whoes |