Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

On Fri, 26 Sep 2003, Tom Lane wrote:

> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> > to a 7.4beta3 database is producing some errors like this:
>
> > ERROR: literal newline found in data
> > HINT: Use "\n" to represent newline.
> > CONTEXT: COPY FROM, line 59
>
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> > CONTEXT: COPY FROM, line 41
>
> Really? 7.2 should dump data \r or \n as the backslash versions ...
> and does in my tests. Can you make a reproducible test case?

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

> > It would be nice to have such occurances echo the table / row they are
> > getting the error on, or maybe just the first 20 or so characters, so
> > they'd be easier to identify.
>
> That's not a bad idea. I think it would be fairly easy now for the
> CONTEXT line of the error message to include the input data line:
>
> CONTEXT: COPY FROM, line 41: "data here ...."
>
> at least up through the field where the error gets thrown, and with some
> limit on the length of the data that will get echoed. If people like
> that idea I'll see about making it happen.

table name too, like Bruce said. The bothersome bit is that in pg_dump,
it says the line, relative to just this part of the copy command, so you
don't even know which table is giving the error.