Excerpts from Pavel Stehule's message of mié jul 04 05:33:48 -0400 2012: > Hello > > 2012/7/3 Matthew Woodcraft <matt...@woodcraft.me.uk>: > > Peter Geoghegan <pe...@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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
