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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Date: 2022-12-22 08:18:13
Message-ID: CAMbWs488Udp_Z7tUm0eUd3gtXZd3Wx2kDGhHat2Di+1UFkc3EA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 21, 2022 at 9:45 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> Also, I think it might be better to take the opportunity to rewrite
> the function to not use recursion. I don't quite see the need for it
> here and it looks like that might have helped contribute to the
> reported issue. Can't we just write this as a while loop instead of
> having the function call itself? It's not as if we need stack space
> for keeping track of multiple parents. A child relation can only have
> 1 parent. It seems to me that we can just walk there by looping.

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.

Thanks
Richard

Attachment Content-Type Size
v1-0001-Fix-translate_col_privs_multilevel.patch application/octet-stream 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-12-22 08:19:24 Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Previous Message Masahiko Sawada 2022-12-22 07:59:30 Re: Force streaming every change in logical decoding