Re: Two constraints with the same name not always allowed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, André Hänsel <andre(at)webkr(dot)de>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Two constraints with the same name not always allowed
Date: 2018-09-06 22:07:51
Message-ID: 23059.1536271671@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeremy Evans 2018-09-06 22:28:43 Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Previous Message Michael Paquier 2018-09-06 21:58:36 Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables