2011/7/18 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> 2011/7/18 Tom Lane <t...@sss.pgh.pa.us>: >>>> 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. > > Read the standard. COLUMN_NAME is defined for use only in > syntax_error_or_access_rule_violation errors that relate to a specific > column. In fact, the spec is written as (SQL:2008 23.1 GR 4-h-ii): > > If the syntax error or access rule violation was for an inaccessible > column, then the value of COLUMN_NAME is the <column name> of that > column. Otherwise, the value of COLUMN_NAME is a zero-length string. > > which suggests that it might be meant *only* for use with > INSUFFICIENT_PRIVILEGE errors that are thrown due to a column ACL. > We can probably extend that to some other syntax errors, like unknown > column or wrong datatype or what have you, but there is nothing here to > suggest that we have to force the issue for errors that don't naturally > relate to exactly one column. And CHECK constraints don't. Consider > "CHECK (f1 > f2)". >
ok, this is relative clean, but so for example, NULL or DOMAIN constraints doesn't affect a COLUMN_NAME? These constraints has no name. 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
