Skip site navigation (1) Skip section navigation (2)

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

From: Jim Nasby <jim(at)nasby(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Hm, table constraints aren't so unique as all that
Date: 2013-01-30 20:12:16
Message-ID: 51097EA0.2020804@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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...


In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2013-01-30 21:05:52
Subject: Re: autovacuum not prioritising for-wraparound tables
Previous:From: Kevin GrittnerDate: 2013-01-30 18:31:50
Subject: Re: autovacuum not prioritising for-wraparound tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group