Re: Two constraints with the same name not always allowed - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Two constraints with the same name not always allowed
Date
Msg-id 23059.1536271671@sss.pgh.pa.us
Whole thread Raw
In response to Re: Two constraints with the same name not always allowed  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-bugs
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 02/09/2018 19:00, Tom Lane wrote:
>> This also points up the lack of a suitable unique index on pg_constraint.
>> It's sort of difficult to figure out what that should look like given that
>> pg_constraint contains two quasi-independent collections of constraints,
>> but maybe UNIQUE(conrelid,contypid,conname) would serve given the
>> reasonable assumption that exactly one of conrelid and contypid is zero.

> Sketches for assertions set both conrelid and contypid to zero.  I think
> the unique constraint would have to include connamespace to support that
> properly.

Well, as I said in the commit message, I'm now of the opinion that
assertions should go in some new catalog.  It was a mistake to put
domain and relation constraints into the same catalog, and I don't
think we ought to double down on that mistake by confusing the
question of "what's this catalog's primary key?" still more.

But yes, *if* we bull ahead and do it the wrong way, that would be
a necessary change.  I don't like it much, because it would fuzz up
the question of whether the unique index actually guarantees only
one instance of a constraint name per relid or typid.

            regards, tom lane


pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Next
From: Jeremy Evans
Date:
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables