On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.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.
Sounds better. Doesn't make much sense as it is now.
> I'm confused by your comment about inheritance --- what cases are
> you thinking this would break?
Well, I made the index unique and got a boat load of errors. I guess I
might have misdiagnosed their cause. I'll have another look.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
