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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Дата
Msg-id 27373.1064609848@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)  ("scott.marlowe" <scott.marlowe@ihs.com>)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> scott.marlowe writes:
>> but I get basically the same thing if I dump it to a .sql file and do:
>> psql dbname <dbname.sql

> Use psql -f dbname.sql instead.

This doesn't seem like a good argument not to add more information to
the CONTEXT line for COPY errors.  Sure, in theory the existing info
should be sufficient, but what if the information is not coming in
through psql?  (For instance, maybe the COPY data is being generated
on-the-fly by some other program.)  Or what if the dump file is so large
you can't easily edit it to determine which line number is in question?
There are plenty of scenarios where it's not all that convenient to
triangulate on a problem from outside information.  Minimalism isn't
really a virtue in error reports anyway.

I'm thinking maybe:
CONTEXT:  COPY tablename, line 41: "data ..."

would serve the purpose nicely.
        regards, tom lane


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

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