On 3/18/25 08:31, Michael Paquier wrote:
On Thu, Feb 13, 2025 at 10:44:33AM -0600, Sami Imseih wrote:
The reason for the change is because "query jumble" will no longer
make sense if the jumble code can now be used for other types of
trees, such as Plan.
I do agree that this needs a single-threaded discussion to achieve a
consensus.
FWIW, I was playing with a sub-project where I was jumbling a portion
of nodes other than Query, and it is annoying to not have a direct
access to jumbleNode(). So, how about doing the refactoring proposed
in v5-0002 with an initialization routine and JumbleNode() as the
entry point for the jumbling, but not rename the existing files
queryjumblefuncs.c and queryjumble.h? That seems doable for this
release, at least.
It seems pretty helpful to me. Having a code for hashing an expression
or subquery, we may design new optimisations. I personally have such a
necessity in a couple of planner extensions.
At the same time, generalising jumbling code we may decide to work on
the JumbleState structure: code related to constant locations may be
replaced with callbacks - let the caller decide what action to take on
each node (not only constants). Of course, it is not for current release.
I don't think that we should expose AppendJumble(), either.
Agree
--
regards, Andrei Lepikhov
