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

Thanks David, for looking at this.

Em ter., 20 de dez. de 2022 às 22:45, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:

> On Wed, 21 Dec 2022 at 13:15, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> > IMO, I think that commit a61b1f7, has an oversight.
> > Currently is losing the result of recursion of function
> translate_col_privs_multilevel.
> >
> > Once the variable result (Bitmapset pointer) is reassigned.
> >
> > Without a test case for this patch.
> > But also, do not have a test case for the current thinko in head.
>
> hmm, that code looks a bit suspect to me too.
>
> Are you able to write a test that shows the bug which fails before
> your change and passes after applying it? I don't think it's quite
> enough to claim that your changes pass make check given that didn't
> fail before your change.
>
No, unfortunately not yet. Of course that test case would be very nice.
But my time for postgres is very limited.
For voluntary work, without any payment, I think what I have contributed is
good.

> 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.
>
I took a look at the code that deals with the array (append_rel_array) and
all the loops seem different from each other and out of any pattern.
Unfortunately, I still can't get this loop to work correctly,
I need to learn more about Postgres structures and the correct way to
process them.
If you can do it, I'd be happy to learn the right way.

regards,
Ranier Vilela