Re: patch for 9.2: enhanced errors

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