| From: | Richard Guo <rguo(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Fix var_is_nonnullable() to account for varreturningtype |
| Date: | 2026-04-10 06:51:43 |
| Message-ID: | E1wB5iR-000GBL-16@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Fix var_is_nonnullable() to account for varreturningtype
var_is_nonnullable() failed to consider varreturningtype, which meant
it could incorrectly claim a Var is non-nullable based on a column's
NOT NULL constraint even when the Var refers to a non-existent row.
Specifically, OLD.col is NULL for INSERT (no old row exists) and
NEW.col is NULL for DELETE (no new row exists), regardless of any NOT
NULL constraint on the column.
This caused the planner's constant folding in eval_const_expressions
to incorrectly simplify IS NULL / IS NOT NULL tests on such Vars. For
example, "old.a IS NULL" in an INSERT's RETURNING clause would be
folded to false when column "a" has a NOT NULL constraint, even though
the correct result is true.
Fix by returning false from var_is_nonnullable() when varreturningtype
is not VAR_RETURNING_DEFAULT, since such Vars can be NULL regardless
of table constraints.
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Reviewed-by: Tender Wang <tndrwang(at)gmail(dot)com>
Reviewed-by: Richard Guo <guofenglinux(at)gmail(dot)com>
Discussion: https://postgr.es/m/CAHg+QDfaAipL6YzOq2H=gAhKBbcUTYmfbAv+W1zueOfRKH43FQ@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f6936bf9da58afd167787635863bae387ae5ba35
Modified Files
--------------
src/backend/optimizer/util/clauses.c | 8 ++++++++
src/test/regress/expected/returning.out | 31 +++++++++++++++++++++++++++++++
src/test/regress/sql/returning.sql | 20 ++++++++++++++++++++
3 files changed, 59 insertions(+)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-04-10 07:18:19 | pgsql: Move afterTriggerFiringDepth into AfterTriggersData |
| Previous Message | Amit Langote | 2026-04-10 06:28:30 | pgsql: Assert index_attnos[0] == 1 in ri_FastPathFlushArray() |