On 1/28/13 6:25 PM, Tom Lane wrote:
I think we need to tighten this down by having index-constraint creation check for conflicts with other constraint types. It also seems like it might be a good idea to put in a unique index to enforce the intended lack of conflicts --- note that the existing index on (conname, connamespace) isn't unique. It's a bit problematic that pg_constraint contains both table-related constraints and domain-related constraints, but it strikes me that we could get close enough by changing pg_constraint_conname_nsp_index to be a unique index on (conname, connamespace, conrelid, contypid). That would fix the problem as long as no pg_constraint entry ever has both conrelid and contypid nonzero; the unique index couldn't catch such an error. But it doesn't seem to me that such a coding error would escape detection anyway.
My belt-and-suspenders mind tells me that there should be a check constraint enforcing that either conrelid IS NOT NULL XOR contypid IS NOT NULL. We routinely do this at work.
Dunno if putting check constraints on catalog tables is possible/sane though...
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
