A couple more things about this patch ...
I went back through the thread and reviewed all the angst about which
fields to provide, especially whether we need CONSTRAINT_SCHEMA.
I agree with the conclusion that we don't. It's in the spec because
the spec supposes that CONSTRAINT_SCHEMA+CONSTRAINT_NAME is a unique
identification for a constraint --- but it is not in Postgres, for
historical reasons that we aren't going to revisit in this patch.
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.
Do we want to add that now?
If we do fix this, either now or later, it's going to require some small
support function very much like errtable() to perform the catalog
lookups for a datatype and set the ErrorData fields. The thought of
dropping such a thing into relerror.c exposes the fact that that
"module" isn't actually very modular. We could choose a different name
for the file but it'd still be pretty questionable as to what its
boundaries are. So I'm a bit inclined to drop relerror.c as such, and
go back to the early design that put errtable() and friends in
relcache.c. The errconstraint() function, not being specific to either
rels or datatypes, perhaps really does belong in elog.c.
Thoughts?
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
