Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id 27373.1064609848@sss.pgh.pa.us
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Peter Eisentraut <peter_e@gmx.net>)
Responses 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>)
List 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 by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: "scott.marlowe"
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)