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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers