> On 3/25/25 00:47, Sami Imseih wrote:
> > I know it was mentioned above by both Michael and Andrei that
> > AppendJumble should not be exposed. I am not sure I agree with
> > that. I think it should be exposed, along with
> > JUMBLE_FIELD, JUMBLE_FIELD_SINGLE and JUMBLE_STRING
> > and _jumbleList.
> It would be helpful if you could provide an example to support the
> reasoning behind exposing this stuff. I assume you want to influence the
> logic of jumbling, correct?
I was actually thinking more about the case which Lukas mentions above [0],
which is jumbling a Plan. So, an extension having access to AppendJumble (
and the macros ) will allow it to create a routine similar to
JumbleNode but that
can deal with the plannodes.
Of course, the same pattern can be applied to other types of nodes.
> Hmm, yes, the macros could prove to be useful to allow extensions to
> compile their own code the manipulations they want to do on the node
> structures they'd like to touch, but wouldn't that mean that they
> would copy in some way a portion of what gen_node_support.pl does?
I feel like gen_node_support.pl should just deal with generating functions
for core jumbling logic, and extensions should be able to build out their
jumbling funcs, and do it simply if they have access to AppendJumble and
friends.
> So based on that workflow I'm not sure turning gen_node_support.pl into a re-usable module
> would help, but that's just my perspective without having built this out (yet).
> 1. Check out the upstream Postgres source for the given version I'm generating jumble code for
> 2. Modify the headers as needed to have the node attributes I want
> 3. Call the gen_node_support.pl via the build process
> 4. Copy out the resulting jumble node funcs/conds
I like this approach, and the artifacts from #4 will be packed with
the extension.
[0] https://www.postgresql.org/message-id/CAP53Pkw7HD%2B3sssn5UcASWLn%2Ba9oRJOM9hXteDCg64JJ662bHQ%40mail.gmail.com
--
Sami Imseih
Amazon Web Services (AWS)
