From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix NULLIF()'s handling of read-write expanded objects. |
Date: | 2024-11-25 23:10:00 |
Message-ID: | E1tFiDQ-003WsY-G0@gemulon.postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix NULLIF()'s handling of read-write expanded objects.
If passed a read-write expanded object pointer, the EEOP_NULLIF
code would hand that same pointer to the equality function
and then (unless equality was reported) also return the same
pointer as its value. This is no good, because a function that
receives a read-write expanded object pointer is fully entitled
to scribble on or even delete the object, thus corrupting the
NULLIF output. (This problem is likely unobservable with the
equality functions provided in core Postgres, but it's easy to
demonstrate with one coded in plpgsql.)
To fix, make sure the pointer passed to the equality function
is read-only. We can still return the original read-write
pointer as the NULLIF result, allowing optimization of later
operations.
Per bug #18722 from Alexander Lakhin. This has been wrong
since we invented expanded objects, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4aba56adcd29c5d9a6f38f9bc428b916e3d08d5d
Modified Files
--------------
src/backend/executor/execExpr.c | 8 ++++++++
src/backend/executor/execExprInterp.c | 14 +++++++++++++-
src/backend/jit/llvm/llvmjit_expr.c | 33 +++++++++++++++++++++++++++++----
src/include/executor/execExpr.h | 1 +
src/test/regress/expected/case.out | 8 ++++++++
src/test/regress/sql/case.sql | 5 +++++
6 files changed, 64 insertions(+), 5 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-11-26 00:28:52 | pgsql: Remove dead code in get_param_path_clause_serials() |
Previous Message | Noah Misch | 2024-11-25 22:43:34 | pgsql: Avoid "you don't own a lock of type ExclusiveLock" in GRANT TABL |