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

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tim McAuley <mcauleyt(at)tcd(dot)ie>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date: 2003-09-26 18:39:57
Message-ID: Pine.LNX.4.33.0309261236090.383-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

On Fri, 26 Sep 2003, Bruce Momjian wrote:

> Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > Tom Lane writes:
> > >> so it appears that cygwin's "echo" generates a different newline style
> > >> than what got put into sql_features.txt. A possible way to fix this is
> > >> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > >> answer. Peter, any thoughts?
> >
> > > There's no clean answer to this on Cygwin. This specific case is just a
> > > little problem that we could solve locally, but in general you'll just end
> > > up annoying people if you require them to use consistent line endings on
> > > Cygwin.
> >
> > Yeah, I was wondering whether you wouldn't propose dropping the newline
> > consistency check. I'm not very comfortable with that, but maybe we
> > should. Bruce?
>
> I posted on that a few minutes ago. Yea, we can drop it, but we risk
> eating carraige returns as data values. I am not sure how consistently
> we output literal carriage returns in old dumps, nor how many apps
> produce on literal carriage returns in COPY. If we conditionally eat
> them, we run the risk of discarding some of their data without warning.
> Perhaps we can throw a warning rather than an error, and adjust initdb
> to be consistent.

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

These show up with little or no context, only the "line number" of the
dump file. Since I'm wrapping these up in pg_dumpall, I don't have the
dump file so I don't know where the error is really occuring. 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.

Is this related to this issue?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-26 18:40:30 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 18:37:47 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-26 18:40:30 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 18:37:47 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-26 18:40:30 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 18:37:47 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)