Re: Hm, table constraints aren't so unique as all that

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