Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Дата
Msg-id CAMbWs4-cnPkfA6YBp8v-8Nf3r6T+rvUm_BSYqqWdhK1J2fgTOg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

On Thu, Dec 22, 2022 at 5:22 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Thu, 22 Dec 2022 at 21:18, Richard Guo <guofenglinux@gmail.com> wrote:
> My best guess is that this function is intended to share the same code
> pattern as in adjust_appendrel_attrs_multilevel.  The recursion is
> needed as 'rel' can be more than one inheritance level below the top
> parent.  I think we can keep the recursion, as in other similar
> functions, as long as we make it right, as in attached patch.

I still think we should have a test to ensure this is actually
working. Do you want to write one?
 
I agree that we should have a test.  According to the code coverage
report, the recursion part of this function is never tested.  I will
have a try to see if I can come up with a proper test case.

Thanks
Richard

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Small miscellaneus fixes (Part II)
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Exit walsender before confirming remote flush in logical replication