Re: postgres error reporting - Mailing list pgsql-general

From Mike Mascari
Subject Re: postgres error reporting
Date
Msg-id 005201c2d781$c18b9aa0$0102a8c0@mascari.com
Whole thread Raw
In response to Re: postgres error reporting  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: postgres error reporting  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
>
> New in 7.3, you can specify an empty COPY column for an
integer.  It has
> to be a zero or some other value.

That's true of course (that you cannot specify an empty column
for an integer). But Chisel's complaint still remains; the error
reporting in some messages (particularly type-related errors)
fails to provide any concrete information as to which attribute
of which table caused the failure. One would have to log queries
to determine where the failure took place. I don't think its
unfair to say that other DBMS products do a better job of
reporting more details of the failure - schema, table,
attribute, etc.

Mike Mascari
mascarm@mascari.com

>
> Chisel Wright wrote:
> > I like postgres, I find I get on much better with it than
mysql.
> > I have one really big problem with it though.
> >
> > Why is the error reporting so bad/vague for failed inserts?
> >
> >   ERROR:  pg_atoi: zero-length string
> >
> > No clues as to which field or piece of data it is
complaining about.
> >
> > Does anyone know how to find this out?



pgsql-general by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Table Partitioning in Postgres:
Next
From: "scott.marlowe"
Date:
Subject: techdocs broken again.