Bruce Momjian wrote:
> 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.
OK, I have applied a patch to make initdb create a COPY file with
consistent end-of-line termination, so it passes the COPY EOL checking.
If we find more cases where load files have intended inconsistent EOL
termination, we can revisit the COPY error for inconsistent EOL
termination.
-- 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