2011/7/18 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/7/18 Tom Lane <tgl@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
>
