Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id 200309261812.h8QICdc21071@candle.pha.pa.us
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Andrew Dunstan <andrew@dunslane.net>)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-hackers
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.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Threads vs Processes
Next
From: Andrew Dunstan
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)