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

From Tom Lane
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id 27560.1064610876@sss.pgh.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)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> The argument that you want a warning because you might have mixed
>> newlines in the file seems less likely than this case where they are
>> using a literal carriage return as a data value at the end of the line.

> I don't agree with that assessment.  Who actually has CRs in their data?

The question isn't so much "who has CRs in their data" as "who is trying
to import data files in which CRs aren't correctly represented as \r" ?
Not anyone upgrading from a recent PG release ... though 7.1 or before
would have an issue.

If we eliminate the mixed-newline check then we will silently discard
CRs that appear at the tail end of the last column of a data line.  This
is somewhat worrisome because the failure will not be obvious.  But in
most cases (CR in the middle of a data field, or in a field that isn't
last), we will detect and report an error due to field count mismatch.
I think that that might be good enough.

If we were designing COPY from scratch today, we'd certainly not think
that a mixed-newline check was appropriate; it's only because of our
historical handling of literal CRs that the question comes up at all.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Rod Taylor
Date:
Subject: Re: 2-phase commit