pgsql: Fix var_is_nonnullable() to account for varreturningtype

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(+)

Browse pgsql-committers by date

  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()