Re: Question about hashed ScalarArrayOpExpr equality semantics

> 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