Hi,
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.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
[1] https://commitfest.postgresql.org/40/3478/
[2] https://commitfest.postgresql.org/40/3224/
[3] https://www.postgresql.org/message-id/94353655-c177-1f55-7afb-b2090de33341%40enterprisedb.com
[4] https://www.postgresql.org/message-id/flat/2847014.1611971629%40sss.pgh.pa.us
