Re: enhanced error fields

Excerpts from Pavel Stehule's message of mié jul 04 05:33:48 -0400 2012:
> Hello
>
> 2012/7/3 Matthew Woodcraft <matthew(at)woodcraft(dot)me(dot)uk>:
> > Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> >> So I took a look at the patch eelog-2012-05-09.diff today. All of the
> >> following remarks apply to it alone.
> >
> > I've been trying out this patch for my own interest (I'm very pleased to
> > see work on this feature), and I have a couple of suggestions from a
> > user's point of view.
> >
> >
> > First: if a not null constraint is violated, the error report includes
> > CONSTRAINT NAME 'not_null_violation'. I think I would find it more
> > useful if CONSTRAINT NAME were left unset rather than given a value that
> > doesn't correspond to a real constraint. A client program can tell it's
> > a null constraint violation from the SQLSTATE.
> >
>
> I don't think so generation some special name is good idea. In this
> case - important values are in COLUMN_NAME, TABLE_NAME, SCHEMA_NAME
>
> postgres=# create table ff(a int not null);
> CREATE TABLE
> postgres=# \set VERBOSITY verbose
> postgres=# insert into ff values(null);
> ERROR: 23502: null value in column "a" violates not-null constraint
> DETAIL: Failing row contains (null).
> LOCATION: ExecConstraints, execMain.c:1527
> COLUMN NAME: a
> TABLE NAME: ff
> SCHEMA NAME: public
> CONSTRAINT NAME: not_null_violation
> CONSTRAINT SCHEMA: public

I think if you don't have a true constraint name to use here, you
shouldn't use anything. When and if we get NOT NULL constraints
catalogued, we can add a constraint name field as a new error field.

In other words +1 for Matthew's opinion.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support