Re: PATCH: Include all columns in default names for foreign key constraints. - Mailing list pgsql-hackers

From Paul Martinez
Subject Re: PATCH: Include all columns in default names for foreign key constraints.
Date
Msg-id CAF+2_SHzBU0tWKvJMZAXfcmrnCwJUeCrAohga0awDf9uDBptnw@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Include all columns in default names for foreign keyconstraints.  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: PATCH: Include all columns in default names for foreign keyconstraints.
List pgsql-hackers
Thanks for the comments!

On Fri, Feb 8, 2019 at 2:11 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql pragma statement
Next
From: Tom Lane
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?