On Tue, Mar 25, 2025 at 8:12 PM Sami Imseih <samims...@gmail.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
v2-0001-Allow-plugins-to-Jumble-an-expression.patch
Description: Binary data
