I wrote:
> Rather what we've got is that constraints are uniquely named among
> those associated with a table, or with a domain.  So the correct
> unique key for a table constraint is table schema + table name +
> constraint name, whereas for a domain constraint it's domain schema +
> domain name + constraint name.  The current patch provides sufficient
> information to uniquely identify a table constraint, but not so much
> domain constraints.  Should we fix that?  I think it'd be legitimate
> to re-use SCHEMA_NAME for domain schema, but we'd need a new nonstandard
> field DOMAIN_NAME (or maybe better DATATYPE_NAME) if we want to fix it.

I have hacked up the code (but not yet the documentation) to support
this, but I found out that there's at least one place where this
definition of the field semantics is a bit awkward.  The issue is that
this definition presupposes that we want to complain about a table or
a domain, never both, because we're overloading both the SCHEMA_NAME
and CONSTRAINT_NAME fields for both purposes.  This is annoying in
validateDomainConstraint(), where we know the domain constraint that
we're complaining about and also the table/column containing the bad
value.  We can't fill in both TABLE_NAME and DATATYPE_NAME because
they both want to set SCHEMA_NAME, and perhaps not to the same value.

Since the error report is about a domain constraint, I don't have a big
problem deciding that the domain has to win this tug-of-war.  And it
could easily be argued that if we had separate fields and filled in
both, an application could get confused about whether we meant a table
constraint or a domain constraint.  (As submitted, the patch would
definitely have made it look like we were complaining about a table
constraint.)  But it's still annoying that we can't represent all the
info that is in the human-readable message.

I'm not sure we should allow corner cases like this to drive the design;
but if anyone has an idea about a cleaner way, let's hear it.

			regards, tom lane

In response to

• Re: enhanced error fields at 2013-01-28 18:00:40 from Tom Lane

Responses

• Re: enhanced error fields at 2013-01-29 14:20:34 from Peter Eisentraut

pgsql-hackers by date

Next:	From: David Rowley	Date: 2013-01-29 05:01:47
	Subject: Re: Hm, table constraints aren't so unique as all that
Previous:	From: Noah Misch	Date: 2013-01-29 03:48:37
	Subject: Re: Re: Doc patch making firm recommendation for settingthe value of commit_delay