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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Дата
Msg-id 27560.1064610876@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: 2-phase commit