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