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 200309262234.h8QMYAu12029@candle.pha.pa.us
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Peter Eisentraut wrote:
> 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.

At this point, we have one mixed-EOL case (initdb, fixable), and one \r
in data case (from 7.2).  Seems the safest solution is to fix initdb and
see what other failure reports we get.

If we downgrade it to a warning, we will not know about the failures;
someone could miss a warning in a dump, but probably will not mess an
error and an empty table.  If we get more reports like initdb, we can
reevaluate, but it seems the safest course is to keep our existing code,
which only removes carriage returns when it quite sure.

--  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: Gavin Sherry
Date:
Subject: Re: 2-phase commit
Next
From: Bruce Momjian
Date:
Subject: Re: plpgsql doesn't coerce boolean expressions to boolean