On Fri, 14 Mar 2025 at 15:46, Michael Paquier <michael@paquier.xyz> wrote:
>
> > On Mar 14, 2025, at 9:27, David Rowley <dgrowleyml@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
inmind 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
doesnot 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/Z9NrnVk7MtMe8uNF@paquier.xyz
