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...