Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Tim McAuley <mcauleyt(at)tcd(dot)ie>
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date: 2003-09-26 21:14:36
Message-ID: 27560.1064610876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-26 22:00:11 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 20:57:28 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-09-26 21:15:37 Re: 2-phase commit
Previous Message Tom Lane 2003-09-26 20:57:28 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Browse pgsql-jdbc by date

  From Date Subject
Next Message Peter Eisentraut 2003-09-26 22:00:11 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Previous Message Tom Lane 2003-09-26 20:57:28 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)