Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> > CONTEXT: COPY FROM, line 2
> >
> > Note that loading this into pico and saving it back out fixes the problem.
> >
> > If I remove the preceding row that doesn't end in a blank field, I get a
> > different error, this one:
> >
> > ERROR: end-of-copy marker does not match previous newline style
> > CONTEXT: COPY FROM, line 2
>
> OK, 'vi' shows it as:
>
> COPY people2 (id, persons) FROM stdin;
> 59 Chance Terry--S
> 60 ^M
> \.
The significant issue here is that we don't want to throw a warning in
this case; it should be an error --- this is clearly a data value we
don't want to discard as part of the end-of-line.
The argument that you want a warning because you might have mixed
newlines in the file seems less likely than this case where they are
using a literal carriage return as a data value at the end of the line.
Seems we should just fix initdb as my patch does and see if we get any
more mixed-newline cases or literal carriage-return data cases. My
guess is that we will get more of the latter.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073