mirror of
https://github.com/postgres/postgres.git
synced 2026-05-21 17:58:48 -04:00
622f8b5301
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 |
||
|---|---|---|
| .. | ||
| data | ||
| expected | ||
| sql | ||
| .gitignore | ||
| GNUmakefile | ||
| Makefile | ||
| parallel_schedule | ||
| pg_regress.c | ||
| pg_regress.h | ||
| pg_regress_main.c | ||
| README | ||
| regress.c | ||
| regressplans.sh | ||
| resultmap | ||
Documentation concerning how to run these regression tests and interpret the results can be found in the PostgreSQL manual, in the chapter "Regression Tests".