Thanks David, for looking at this. Em ter., 20 de dez. de 2022 às 22:45, David Rowley <dgrowle...@gmail.com> escreveu:
> On Wed, 21 Dec 2022 at 13:15, Ranier Vilela <ranier...@gmail.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
