> On Mon, Mar 24, 2025 at 02:36:05PM -0500, Sami Imseih wrote:
> >> Ideally we can also land the jumble funcs work in the other thread
> >> to allow extensions to re-use the
> >> in-core logic for jumbling expressions found in plan node trees.
> >
> > IIUC, there should be a refactor I am working on at this moment to make that
> > possible [0]
>
> That would be nice, thanks.
As mentioned in [0], I spent some time thinking about making some of the core
jumbling facilities available to plugins, and I have several patches to share.
First, none of the changes change the names of the files from queryjumblefuncs.c
to something more generic, as there was some resistance to that idea in this
thread. I will keep it as is for now, and this can be revisited at a
later time, if need be.
So, v1-0001 provides the following to an extension:
InitializeJumbleState - to initialize a jumble state
JumbleNode - To jumble an expression
HashJumbleState - To produce the 64-bit hash from the jumble state
Also, an Assert was added inside RecordConstLocation to assert
that the jumble state was initialized with record_clocations.
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.
I am afraid that if we don't expose these routines/macros, the
extension will have
to re-invent those wheels. This is not included in v1-0001, but If
there is no objection,
I can update the patch. Thoughts?
[0] https://www.postgresql.org/message-id/Z9khOo14yzZHCnmn%40paquier.xyz
