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

On Fri, 26 Sep 2003, Tom Lane wrote:

> "scott.marlowe" <scott.marlowe@ihs.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.