Re: ExecRTCheckPerms() and many prunable partitions

On Fri, Oct 7, 2022 at 3:49 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Fri, Oct 7, 2022 at 1:25 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > On Fri, Oct 7, 2022 at 10:04 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > On Thu, Oct 6, 2022 at 10:29 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > > Actually, List of Bitmapsets turned out to be something that doesn't
> > > > just-work with our Node infrastructure, which I found out thanks to
> > > > -DWRITE_READ_PARSE_PLAN_TREES. So, I had to go ahead and add
> > > > first-class support for copy/equal/write/read support for Bitmapsets,
> > > > such that writeNode() can write appropriately labeled versions of them
> > > > and nodeRead() can read them as Bitmapsets. That's done in 0003. I
> > > > didn't actually go ahead and make *all* Bitmapsets in the plan trees
> > > > to be Nodes, but maybe 0003 can be expanded to do that. We won't need
> > > > to make gen_node_support.pl emit *_BITMAPSET_FIELD() blurbs then; can
> > > > just use *_NODE_FIELD().
> > >
> > > All meson builds on the cfbot machines seem to have failed, maybe
> > > because I didn't update src/include/nodes/meson.build to add
> > > 'nodes/bitmapset.h' to the `node_support_input_i` collection. Here's
> > > an updated version assuming that's the problem. (Will set up meson
> > > builds on my machine to avoid this in the future.)
> >
> > And... noticed that a postgres_fdw test failed, because
> > _readBitmapset() not having been changed to set NodeTag would
> > "corrupt" any Bitmapsets that were created with it set.
>
> Broke the other cases while fixing the above. Attaching a new version
> again. In the latest version, I'm setting Bitmapset.type by hand with
> an XXX comment nearby saying that it would be nice to change that to
> makeNode(Bitmapset), which I know sounds pretty ad-hoc.

Sorry, I attached the wrong patches with the last email. The
"correct" v22 attached this time.

Wondering if it might be a good idea to reorder the patches such that
the changes that move extraUpdatedCols out of RangeTblEntry (patches
0003 and 0004) can be considered/applied independently of the changes
that move permission-checking-related fields out of RangeTblEntry
(patch 0001). The former seem more straightforward except of course
the Bitmapset node infrastructure changes.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com