Wrong result for whole-row IS NOT NULL with dropped columns

From: "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
To: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Wrong result for whole-row IS NOT NULL with dropped columns
Date: 2026-10-20 15:05:01
Message-ID: DM9RAXA7RBH4.1O1CGGXT98IDY@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While working on another thread related with virtual generated columns I
found that a whole-row IS NOT NULL test returns false for a row with no
null fields if the table also has a dropped column:

CREATE TABLE t (a int, b int GENERATED ALWAYS AS (a * 2) VIRTUAL, dropme int);
ALTER TABLE t DROP COLUMN dropme;
INSERT INTO t VALUES (1);

SELECT t, t IS NOT NULL AS is_not_null FROM t;
t | is_not_null
-------+-------------
(1,2) | f
(1 row)

The same happens with a CHECK constraint, which can't be added because
no row can satisfy it, and when it's added as NOT VALID every new row
is rejected:

ALTER TABLE t ADD CONSTRAINT wr CHECK (t IS NOT NULL);
ERROR: check constraint "wr" of relation "t" is violated by some row

With a stored generated column, or without the dropped column, it
works as expected.

EXPLAIN shows that the planner has folded the whole test to a
constant:

EXPLAIN (VERBOSE, COSTS OFF) SELECT t IS NOT NULL FROM t;
QUERY PLAN
--------------------------
Seq Scan on public.t
Output: false
(2 rows)

IIUC what happens is that to expand the virtual column the whole-row
Var is turned into a RowExpr, and since this is a named rowtype
expandRTE() includes a null int4 Const as placeholder for the dropped
column. Then eval_const_expressions() breaks ROW(...) IS [NOT] NULL
into tests on each field, sees the null constant and refutes the
IS NOT NULL. The executor doesn't have this problem because
ExecEvalRowNullInt() skips dropped attributes, so the result depends on
whether the test was simplified at plan time or not.

Virtual generated columns are just the easiest way to reach this. The
same placeholder is added by coerce_record_to_complex() when casting a
row to a named rowtype, so this is also wrong on master without any
generated column involved:

CREATE TABLE ts (a int, dropme int, b int);
ALTER TABLE ts DROP COLUMN dropme;
EXPLAIN (VERBOSE, COSTS OFF) SELECT ROW(a, b)::ts IS NOT NULL FROM ts;
QUERY PLAN
-----------------------
Seq Scan on public.ts
Output: false
(2 rows)

The attached patch fixes this by looking up the rowtype's tuple
descriptor when simplifying a NullTest on a RowExpr of a named
composite type and skipping the fields that correspond to dropped
columns, which matches what the executor does. With the patch the
EXPLAIN above shows ((a IS NOT NULL) AND (b IS NOT NULL)). I've added
regression tests on generated_virtual.sql and rowtypes.sql.

The folding code is old, so the ROW()::type case is not new. I've
checked that the EXPLAIN above also shows "Output: false" on PG 14, so I
think that all supported branches are affected and this should be
backpatched. The virtual generated column case only applies to 18 and
master, so perhaps for 17 and older we need a different fix.

Thoughts?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

Attachment Content-Type Size
v1-0001-Ignore-dropped-columns-when-simplifying-ROW-.-IS-.patch text/plain 8.9 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-10-20 15:08:56 Re: 035_standby_logical_decoding might fail due to FATAL message lost inside libpq
Previous Message Tom Lane 2026-10-20 15:02:37 Re: [PATCH] initdb: map Windows' new Canadian time zone names