Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET

On Fri, 14 Mar 2025 at 14:51, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
>
> > On Mar 14, 2025, at 8:15, Sami Imseih <samimseih(at)gmail(dot)com> wrote:
> >> FWIW, another idea I have on top of my mind is the addition of a
> >> counter in JumbleState that we increment each time we enter
> >> _jumbleNode(), then simply call JUMBLE_FIELD_SINGLE() after the
> >> incrementation. And we can rely on this counter to be unique each
> >> time we jumble a node..
> >
> > With this approach, the author of the custom function will need
> > to remember to increment the counter, right?
>
> Actually, no. _jumbleNode() is the unique entry point we use when jumbling a sub-Node in a bigger Node structure, so custom functions don’t need to touch it.

Err, what about non-node types? Those'll go to AppendJumble().

I think basically everyone here apart from you is having a hard time
understanding what additional benefits your counter solution brings
over just ensuring we always AppendJumble with something, regardless
of the field's value. I do want to understand what you're concerned
about but you've demonstrated nothing to us about the "always jumble
something" idea that breaks. Your example custom function broke that
rule as it skipped doing anything when "expr->field1 == 0".

Anyway, let's see your patch so we can judge actual code rather than
waste our time arguing over assumptions about what the hypothetical
code is and does.

David