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

From Peter Eisentraut
Subject Re: PATCH: Include all columns in default names for foreign keyconstraints.
Date
Msg-id 4ef02402-701e-9676-5010-74b8352d28f5@2ndquadrant.com
Whole thread Raw
In response to PATCH: Include all columns in default names for foreign key constraints.  (Paul Martinez <hellopfm@gmail.com>)
Responses Re: PATCH: Include all columns in default names for foreign key constraints.  (Paul Martinez <hellopfm@gmail.com>)
List pgsql-hackers
On 13/01/2019 01:55, Paul Martinez wrote:
> The two constraints have nearly identical names. With my patch the default names
> will include both column names, so we have we will instead have this output:
> 
>  Foreign-key constraints:
>   "comments_tenant_id_commenter_id_fkey" FOREIGN KEY (tenant_id,
> commenter_id) REFERENCES users(tenant_id, id)
>   "comments_tenant_id_post_id_fkey" FOREIGN KEY (tenant_id, post_id)
> REFERENCES posts(tenant_id, id)
> 
> This makes the default names for foreign keys in line with the default names
> for indexes. Hopefully an uncontroversial change!

I think this is a good change.

> 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.

> 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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: ON SELECT rule on a table without columns
Next
From: Amit Khandekar
Date:
Subject: Re: Pluggable Storage - Andres's take