Re: patch for 9.2: enhanced errors

2011/7/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Tom,
>>> No, I don't.  You're adding complication to solve a problem that doesn't
>>> need to be solved.  The standard says to return the name of the
>>> constraint for a constraint-violation failure.  It does not say anything
>>> about naming the associated column(s).  COLUMN_NAME is only supposed to
>>> be defined for certain kinds of errors, and this isn't one of them.
>
>> Are we talking about FK constraints here, or CHECK contstraints?
>
> Either one.  They both have the potential to reference more than one
> column, so if the committee had meant errors to try to identify the
> referenced columns, they'd have put something other than COLUMN_NAME
> into the standard.  They didn't.

Personally, I see a sense for COLUMN_NAME field only with relation to
CHECK_CONSTRAINT - for any other constraint using a COLUMN_NAME is
based on parsing a constraint rule - and I don't believe so the
standard is based in it. Column check constraint is attached
explicitly to one column - but this relation should not be based on
semantic.

We can check DB2 implementation.

Regards
Pavel

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>