Re: postgres error reporting

From: "Mike Mascari" <mascarm(at)mascari(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Chisel Wright" <chisel(at)herlpacker(dot)co(dot)uk>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: postgres error reporting
Date: 2003-02-18 19:13:01
Message-ID: 005201c2d781$c18b9aa0$0102a8c0@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)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(at)mascari(dot)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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dann Corbit 2003-02-18 19:13:23 Re: Table Partitioning in Postgres:
Previous Message Daniel Schuchardt 2003-02-18 19:08:27 Re: BLOB or BYTEA field

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-02-18 19:40:42 Re: postgres error reporting
Previous Message Bruce Momjian 2003-02-18 19:04:47 Re: postgres error reporting