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 confused by your comment about inheritance --- what cases are
you thinking this would break?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
