Re: patch for 9.2: enhanced errors

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)".

regards, tom lane