Fix incorrect logic for hashed IN / NOT IN with non-strict operators ExecEvalHashedScalarArrayOp(), when using a strict equality function, performs a short-circuit when looking up NULL values. When the function is non-strict, the code incorrectly looked up the hash table for a zero-valued Datum, which could have resulted in an accidental true return if the hash table contained zero valued Datum, or could result in a crash for non-byval types.
Here we fix this by adding an extra step when we build the hash table to check what the result of a NULL lookup would be. This requires looping over the array and checking what the non-hashed version of the code would do. We cache the results of that in the expression so that we can reuse the result any time we're asked to search for a NULL value. It's important to note that non-strict equality functions are free to treat any NULL value as equal to any non-NULL value. For example, someone may wish to design a type that treats an empty string and NULL as equal. All built-in types have strict equality functions, so this could affect custom / user-defined types. Author: Chengpeng Yan <[email protected]> Author: David Rowley <[email protected]> Reviewed-by: ChangAo Chen <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/109de35b705cac265185459ae947eb72810c3a82 Modified Files -------------- src/backend/executor/execExprInterp.c | 109 ++++++++++++++++++++++------ src/include/executor/execExpr.h | 4 ++ src/test/regress/expected/expressions.out | 113 +++++++++++++++++++++++++----- src/test/regress/sql/expressions.sql | 70 ++++++++++++++++-- 4 files changed, 253 insertions(+), 43 deletions(-)
