> While looking at the hashed ScalarArrayOpExpr path, I noticed that the linear
> and hashed evaluation paths can give different answers if the comparison
> function returns NULL for non-NULL inputs.
>
> The part I am trying to understand is what assumption the hashed path is
> allowed to make about equality operators used for hashing. Does declaring an
> equality operator as HASHES / putting it in a hash opclass imply that, for
> non-NULL inputs, the equality result is a definite true or false value?
>
> ...
>
> I realize this is a strange equality operator, and that may be the whole
> point.
> For a hash table lookup, it seems reasonable to need a definite answer to
> "does
> this stored key match the lookup key?". On the other hand, ScalarArrayOpExpr
> itself has SQL three-valued semantics, and the linear path does preserve the
> comparison's NULL result.
>
> So my question is: is the hashed path allowed to assume that hashable equality
> operators never return NULL for non-NULL inputs, or should it preserve the
> same
> UNKNOWN result that the linear ScalarArrayOpExpr evaluation would produce?
There is a comment in test_opexpr_is_hashable():
/*
* The combining operator must be hashable and strict. The need for
* hashability is obvious, since we want to use hashing. Without
* strictness, behavior in the presence of nulls is too unpredictable.
We
* actually must assume even more than plain strictness: it can't yield
* NULL for non-null inputs, either (see nodeSubplan.c). However, hash
* indexes and hash joins assume that too.
*/
We assume that a strict operator can't yield NULL for non-null inputs. Not sure
whether we can also assume this for a non-strict operator.
--
Regards,
ChangAo Chen
