| 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: | Whole Thread | Raw Message | 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 |
| 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 |