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