agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:03 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:03 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/035c520db86676da771bf646d1a1ee1913a38f3a Modified Files -------------- src/backend/executor/execExprInterp.c | 113 +++++++++++++---- src/include/executor/execExpr.h | 4 + src/test/regress/expected/expressions.out | 203 +++++++++++++++++++++++++----- src/test/regress/sql/expressions.sql | 114 +++++++++++++++-- 4 files changed, 368 insertions(+), 66 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:04 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3fda3e12f41b5e64d665f881f38ccba5d8d31e02 Modified Files -------------- src/backend/executor/execExprInterp.c | 113 +++++++++++++---- src/include/executor/execExpr.h | 4 + src/test/regress/expected/expressions.out | 203 +++++++++++++++++++++++++----- src/test/regress/sql/expressions.sql | 114 +++++++++++++++-- 4 files changed, 368 insertions(+), 66 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:04 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a2a0060d5d8fb64ffdb43ff768762a3f4674b78d Modified Files -------------- src/backend/executor/execExprInterp.c | 113 +++++++++++++---- src/include/executor/execExpr.h | 4 + src/test/regress/expected/expressions.out | 203 +++++++++++++++++++++++++----- src/test/regress/sql/expressions.sql | 114 +++++++++++++++-- 4 files changed, 368 insertions(+), 66 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:05 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:05 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/622f8b53014ed62eda857cec192978db8cca8a70 Modified Files -------------- src/backend/executor/execExprInterp.c | 113 +++++++++++++---- src/include/executor/execExpr.h | 4 + src/test/regress/expected/expressions.out | 203 +++++++++++++++++++++++++----- src/test/regress/sql/expressions.sql | 114 +++++++++++++++-- 4 files changed, 368 insertions(+), 66 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera @ 2026-04-24 02:05 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2026-04-24 02:05 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 ------ 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(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-04-24 02:05 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-24 02:03 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org> 2026-04-24 02:03 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org> 2026-04-24 02:04 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org> 2026-04-24 02:04 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org> 2026-04-24 02:05 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org> 2026-04-24 02:05 pgsql: Fix incorrect logic for hashed IN / NOT IN with non-strict opera David Rowley <drowley@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox