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

Поиск
Список
Период
Сортировка
От Paul Martinez
Тема Re: PATCH: Include all columns in default names for foreign key constraints.
Дата
Msg-id CAF+2_SHzBU0tWKvJMZAXfcmrnCwJUeCrAohga0awDf9uDBptnw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: Include all columns in default names for foreign keyconstraints.  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: PATCH: Include all columns in default names for foreign keyconstraints.
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql pragma statement
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should we increase the default vacuum_cost_limit?