On Fri, 14 Mar 2025 at 15:46, Michael Paquier <mich...@paquier.xyz> wrote: > > > On Mar 14, 2025, at 9:27, David Rowley <dgrowle...@gmail.com> wrote: > > 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". > > Because what I’ve mentioned is the kind of case I’ve wanted as supported when > designing this facility, keeping also in mind that we may use this stuff for > more than just Querys. If you’d rather discard what the argument I’ve done > upthread, well, I guess that you’re free to do so and bypass any comments I > have. Now I do think that what’s been sent does not check all the boxes if we > want a solution other than shifting the fields of a Node.
I don't think I'm discarding them... As far as I'm aware, your remaining concern is with custom jumble functions and you showed an example in [1] of a hypothetical jumble function that could cause the same bug as this thread is discussing. My response to that was that the custom jumble function is broken and should be fixed, which seems to me to be analogous to Ivan's proposal to fix _jumbleNode() to do something with NULL pointers. I now can't tell which of the following is true: 1) I've missed one of your concerns, or; 2) you want to find a way to make badly coded custom jumble functions not suffer from this bug, or; 3) you think that adding jumble bytes unconditionally regardless of the field's value still does not fix the bug in question, or; 4) something else. It would be good to know which of these it is. David [1] https://postgr.es/m/z9nrnvk7mtme8...@paquier.xyz
