On Mon, Oct 17, 2022 at 6:30 PM Amit Langote <amitlangot...@gmail.com> wrote: > For a couple of patches that I am working on ([1], [2]), I have needed > to put Bitmapsets into a List that is in turn part of a Plan tree or a > Node tree that may be written (using outNode) and read (using > nodeRead). Bitmapsets not being a Node themselves causes the > write/read of such Plan/Node trees (containing Bitmapsets in a List) > to not work properly. > > So, I included a patch in both of those threads to add minimal support > for Bitmapsets to be added into a Plan/Node tree without facing the > aforementioned problem, though Peter E suggested [3] that it would be > a good idea to discuss it more generally in a separate thread, so this > email. Attached a patch to make the infrastructure changes necessary > to allow adding Bitmapsets as Nodes, though I have not changed any of > the existing Bitmapset that are added either to Query or to > PlannedStmt to use that infrastructure. That is, by setting their > NodeTag and changing gen_node_support.pl to emit > WRITE/READ_NODE_FIELD() instead of WRITE/READ_BITMAPSET_FIELD() for > any Bitmapsets encountered in a Node tree. One thing I am not quite > sure about is who would be setting the NodeTag, the existing routines > in bitmapset.c, or if we should add wrappers that do. > > Actually, Tom had posted about exactly the same thing last year [4], > though trying to make Bitmapset Nodes became unnecessary after he > resolved the problem that required making Bitmapsets Nodes by other > means -- by getting rid of the field that was a List of Bitmapset > altogether. Maybe I should try to do the same in the case of both [1] > and [2]? In fact, I have tried getting rid of the need for List of > Bitmapset for [1], and I like the alternative better in that case, but > for [2], it still seems that a List of Bitmapset may be better than > List of some-new-Node-containing-the-Bitmapset.
FTR, this has been taken care of in 5e1f3b9ebf6e5. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com