On Fri, 26 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e@gmx.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?