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

From scott.marlowe
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id Pine.LNX.4.33.0309261455330.1399-100000@css120.ihs.com
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 26 Sep 2003, Tom Lane wrote:

> 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.

Yeah, just having the table name and line number would be plenty for me.  
It's the lack of a table name that makes it so frustrating.  I had to 
basically dump / restore the tables one at a time to figure out which one 
was causing the error.  On a database with hundreds of tables, that could 
be painful.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Tom Lane
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)