Re: PATCH: Include all columns in default names for foreign key constraints.

From: Paul Martinez <hellopfm(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: Include all columns in default names for foreign key constraints.
Date: 2019-03-09 21:27:29
Message-ID: CAF+2_SHzBU0tWKvJMZAXfcmrnCwJUeCrAohga0awDf9uDBptnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the comments!

On Fri, Feb 8, 2019 at 2:11 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> On 13/01/2019 01:55, Paul Martinez wrote:
> > I pretty much just copied and pasted the implementation from
> > ChooseIndexNameAddition and placed it in src/backend/commands/tablecmds.c.
>
> The use of "name2" in the comment doesn't make sense outside the context
> of indexcmds.c. Maybe rewrite that a bit.

Updated.

> > Regression tests are in src/test/regress/sql/foreign_key.sql. I create two
> > composite foreign keys on table, one via the CREATE TABLE statement, and the
> > other in a ALTER TABLE statement. The generated names of the constraints are
> > then queried from the pg_constraint table.
>
> Existing regression tests already exercise this, and they are failing
> all over the place because of the changes of the generated names. That
> is to be expected. You should investigate those failures and adjust the
> "expected" files. Then you probably don't need your additional tests.
>
> It might be worth having a test that runs into the 63-character length
> limit somehow.

Yikes, sorry about that. Some tests are failing on my machine because of dynamic
linking issues and I totally missed all the foreign key failures. I think I've
fixed all the tests. I changed the test I added to test the 63-character limit.

Attached is an updated patch.

- Paul

Attachment Content-Type Size
foreign-key-constraint-names-v2.patch application/octet-stream 40.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-09 22:14:25 Re: Should we increase the default vacuum_cost_limit?
Previous Message Pavel Stehule 2019-03-09 21:17:31 Re: proposal: plpgsql pragma statement