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.
Here's an updated patch (code only, sans documentation) that fixes that
and adds some other refactoring that I thought made for improvements.
I think this is ready to commit except for the documentation.
I eventually concluded that the two ALTER DOMAIN call sites in
typecmds.c should report the table/column name (with errtablecol),
even though in principle the auxiliary info ought to be about the
domain. The reason is that the name of the domain is nearly useless
here --- you probably know it already, if you're issuing an ALTER for
it. In fact, we don't even bother to provide the name of the domain
at all in either human-readable error message. On the other hand,
the location of the offending value could be useful info. So I think
usefulness should trump principle there.
regards, tom lane
eelog7.patch.gz
Description: eelog7.patch.gz
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
