Re: Two constraints with the same name not always allowed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: 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-02 22:31:04
Message-ID: 2152.1535927464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> I think the code supposes that checking for duplicate relation name
> is sufficient; but of course it is not if we want a table's constraints
> to have distinct names, since they may not all correspond to indexes.
> I do not think we can back-patch a change here --- it might break
> databases that are working satisfactorily today. But it seems like
> we could tighten this up in HEAD and maybe v11.

Attached is a draft patchset for this.

0001 replaces the existing index with a unique one and makes necessary
backend code adjustments. Said adjustments could have been as simple
as s/ConstraintRelidIndexId/ConstraintRelidTypidNameIndexId/g -- I tried
that, and it passed regression tests -- but I couldn't resist the
temptation to fix a few places that could make better use of the
redesigned index.

0002 adds user-friendliness by installing a nicer error message for
the complained-of case and by improving ChooseIndexName to avoid
autogenerating index names that will conflict with existing constraints.

I didn't look for possible documentation changes yet, but I think the
code changes are OK.

regards, tom lane

Attachment Content-Type Size
0001-enforce-constraint-name-uniqueness.patch text/x-diff 35.8 KB
0002-enforce-constraint-name-uniqueness-more.patch text/x-diff 12.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message jimmy 2018-09-03 03:10:33 Re:Re: Re: Re: Re: Re: Bug: ERROR: invalid cache ID: 42 CONTEXT: parallel worker
Previous Message Tom Lane 2018-09-02 18:55:20 Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query