agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: David Rowley <drowley@postgresql.org>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera
Date: Fri, 24 Apr 2026 02:03:30 +0000
Message-ID: <E1wG5tC-002Qe8-0h@gemulon.postgresql.org> (raw)
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 <chengpeng_yan@outlook.com>
Author: David Rowley <dgrowleyml@gmail.com>
Reviewed-by: ChangAo Chen <cca5507@qq.com>
Discussion: https://postgr.es/m/A16187AE-2359-4265-9F5E-71D015EC2B2D@outlook.com
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/94219a73f79d49c0f3576af57fa8241fbf230395
Modified Files
--------------
src/backend/executor/execExprInterp.c | 116 +++++++++++++----
src/include/executor/execExpr.h | 4 +
src/test/regress/expected/expressions.out | 203 +++++++++++++++++++++++++-----
src/test/regress/sql/expressions.sql | 114 +++++++++++++++--
4 files changed, 369 insertions(+), 68 deletions(-)
view thread (6+ messages) latest in thread
Message-ID: <E1wG5tC-002Qe8-0h@gemulon.postgresql.org>
Permalink: ../E1wG5tC-002Qe8-0h@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1wG5tC-002Qe8-0h@gemulon.postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: drowley@postgresql.org, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera
In-Reply-To: <E1wG5tC-002Qe8-0h@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox