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