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

2019-03-13 Thread Peter Eisentraut
On 2019-03-09 22:27, Paul Martinez wrote: > 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. > >

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

2019-03-09 Thread Paul Martinez
Thanks for the comments! On Fri, Feb 8, 2019 at 2:11 AM Peter Eisentraut 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 t

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

2019-02-08 Thread Peter Eisentraut
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 (tenan

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

2019-01-12 Thread Vik Fearing
On 13/01/2019 01:55, Paul Martinez wrote: > This is my first submission to Postgres, so I'm not entirely sure what the > protocol is here to get this merged; should I add this patch to the 2019-03 > Commitfest? I haven't looked at the patch yet, but I think it's a good idea and anyway yes, please

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

2019-01-12 Thread Paul Martinez
Hello! I have written a small patch to modify the default names for foreign key constraints. Currently if the foreign key is composed of multiple columns we only use the first one in the constraint name. This can lead to similar constraint names when two foreign keys start with the same column. Th