Re: Reducing some DDL Locks to ShareLock

Simon Riggs <simon(at)2ndQuadrant(dot)com> 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 confused by your comment about inheritance --- what cases are
you thinking this would break?

regards, tom lane