On Fri, 14 Mar 2025 at 14:51, Michael Paquier <mich...@paquier.xyz> wrote: > > > > On Mar 14, 2025, at 8:15, Sami Imseih <samims...@gmail.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
