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.
