|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
|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|