Re: restore whoes

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> In the examples given, the error didn't show up till later rows, in
> >> fields where there was no \r anywhere.
>
> > Hard to imagine why a failure would occur on anything but the first row.
>
> Simple: suppose the dumped data contains \ \n in the body of a field,
> which is the currently-accepted representation for a data newline.
> Microsoft munges this to \ \r \n, which will now be read by COPY IN as a
> backslashed \r (ie, a data \r) followed by a non-escaped newline.
> Ergo, that's the end of the current row. No error is detected (since a
> datatype that could have contained a data \n is unlikely to reject a
> data \r). Then parsing resumes for the next row at the next input
> character. We're totally out of sync and will produce lord only knows
> what peculiar error message when, eventually, some datatype input
> converter doesn't like what it's given. But that could be many rows
> later than where the problem was.
>
> Part of the problem here is that COPY IN will accept a "short" row (one
> with fewer fields than the table actually has columns). So early
> termination of a line isn't recognizable as an error unless the last
> column that receives some data manages to recognize a formatting error.
> Personally I think it would be a good idea to change that --- but I
> suppose you'll complain that that might break existing applications,
> even though the "feature" has never been documented.

No, I will not complain at all. We should not accept short rows,
period. It is reasonable to expect a full row every time. I just think
forcing the escape of \r isn't reasonable.

--
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