Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators

On Mon, 20 Apr 2026 at 01:06, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> If we need to assume the non-strict function could return false on
> NULL = non-NULL, then we could test for that when inserting the first
> datum into the hash table and store the behaviour in the expression.
> It may also be worth doing that check for NULL = NULL so that we don't
> need to call the equals function every time we see a NULL.
>
> I'll need to dig a bit deeper to see if we've written down any rules
> about non-strict equality functions anywhere...

Of course, it is possible to make the strict function do that, and
non-hashed IN / NOT IN handles it, so the hashed version shouldn't
have an excuse to not do the right thing.

I've attached a version that "probes" the equality function for its
NULL = NULL behaviour and its NULL = non-NULL behaviour and returns
whatever the result of the probe was at the appropriate time.

What I came up with does feel quite elaborate, so I'd quite like a 2nd opinion.

The patch does assume that the non-strict function will return the
same thing for NULL = non-NULL as it will for non-NULL = NULL.
Technically, if you coded the function to do something different
there, the hashed vs non-hashed could differ in their result. My
thoughts there, if someone is expecting anything sane out of such an
equality function, then they're probably going to be disappointed due
to various other optimisations we have.

David