On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > On Tue, 2008-10-07 at 10:05 -0400, Robert Haas wrote: > >>> 3. The patch introduces a slight weirdness: if you create two FKs on the > >>> same column at the same time you end up with two constraints with > >>> identical names. Drop constraint then removes them both, though in other > >>> respects they are both valid, just not uniquely. CREATE INDEX avoids > >>> this by way of the unique index on relname. The equivalent index on > >>> pg_constraint is not unique, though *cannot* be made unique without > >>> breaking some corner cases of table inheritance. > >> > >> Urk... this seems pretty undesirable. > > > OK, but please say what behaviour you would like in its place. > > I wonder whether this could be helped if we refactored pg_constraint. > The lack of a useful pkey for it has been annoying me for awhile, > and I think it stems from a misguided choice to put table and domain > constraints into the same catalog. Suppose that > > * table constraints go into pg_relation_constraint, with a unique key > on (conrelid, conname) > > * domain constraints go into pg_domain_constraint, with a unique key > on (contypid, conname) > > * pg_constraint can still exist as a union view, for client > compatibility > > Then the unique key would prevent concurrent creation of > identically-named constraints for the same relation.
I'm planning to squeeze this refactoring work in now also before freeze, unless somebody else wants to pick this up? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
