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