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@woodcraft.me.uk>:
> > Peter Geoghegan <peter@2ndquadrant.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@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support