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)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |
Список | 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 по дате отправления: