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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Дата
Msg-id 25822.1064602882@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  ("scott.marlowe" <scott.marlowe@ihs.com>)
Список pgsql-hackers
"scott.marlowe" <scott.marlowe@ihs.com> writes:
> I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database 
> to a 7.4beta3 database is producing some errors like this:

> ERROR:  literal newline found in data
> HINT:  Use "\n" to represent newline.
> CONTEXT:  COPY FROM, line 59

> ERROR:  literal carriage return found in data
> HINT:  Use "\r" to represent carriage return.
> CONTEXT:  COPY FROM, line 41

Really?  7.2 should dump data \r or \n as the backslash versions ...
and does in my tests.  Can you make a reproducible test case?



> It would be nice to have such occurances echo the table / row they are
> getting the error on, or maybe just the first 20 or so characters, so
> they'd be easier to identify.

That's not a bad idea.  I think it would be fairly easy now for the
CONTEXT line of the error message to include the input data line:
CONTEXT:  COPY FROM, line 41: "data here ...."

at least up through the field where the error gets thrown, and with some
limit on the length of the data that will get echoed.  If people like
that idea I'll see about making it happen.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)