2011/7/18 Tom Lane <t...@sss.pgh.pa.us>: > Josh Berkus <j...@agliodbs.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
