Re: Proposal - Allow extensions to set a Plan Identifier

On Tue, Mar 25, 2025 at 8:12 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:

> So this comes down to forking the Postgres code to do the job. What I
>> had in mind was a slightly different flow, where we would be able to
>> push custom node attributes between the header parsing and the
>> generation of the extension code. If we do that, there would be no
>> need to fork the Postgres code: extensions could force the definitions
>> they want to the nodes they want to handle, as long as these do not
>> need to touch the in-core query jumble logic, of course.
>
>
> Allowing extensions to generate code for custom node attributes could be
> taken up in 19. What about for 18 we think about exposing AppendJumble,
> JUMBLE_FIELD, JUMBLE_FIELD_SINGLE and JUMBLE_STRING?
>

+1, I think exposing the node jumbling logic + ability to jumble values for
extensions would make a big difference to get into 18, specifically for
allowing extensions to do plan ID calculations efficiently.

Attached a rebased version that accounts for the changes in f31aad9b0 and
ad9a23bc4, and also makes AppendJumble* available, as well as two helper
defines JUMBLE_VALUE and JUMBLE_VALUE_STRING. These are intended to work on
values, not nodes, because I think that requiring the caller to have a
local "expr" variable doesn't seem like a good API.

I've also intentionally reduced the API surface area and not allowed
initializing a jumble state that records constant locations / not exported
RecordConstLocations. I think the utility of that seems less clear
(possibly out-of-core queryid customization with a future extension hook in
jumbleNode) and requires more refinement.

Thoughts?

Thanks,
Lukas

--
Lukas Fittl