Unknown column references resolve to NULL instead of raising 42703 — WHERE/ORDER BY/UPDATE silently misbehave, including on fixed-schema engines

[emanzx]

Version / build tested against

origin/main @ 2886155

Deployment mode

Origin — single node (local)

Engine(s) involved

Document (schemaless), Document (strict), Key-Value

Summary

A column name that does not exist in the collection resolves to NULL everywhere instead of raising 42703 (undefined_column). Projection returns NULL-filled rows, WHERE treats the column as NULL (so = <value> silently matches nothing and IS NULL matches everything), ORDER BY silently no-ops, and UPDATE ... WHERE <unknown> = ... silently updates zero rows. This affects the strict and kv engines too, where the schema is fixed and a missing field cannot be schemaless-by-design. Every typo'd identifier in an application query returns plausible-but-wrong results with no error — the same silent-folding class as the undefined-function and division-by-zero paths that now raise, but on the column-resolution side, which still folds.

Steps to reproduce

CREATE COLLECTION probe (id INT PRIMARY KEY, x INT);
INSERT INTO probe (id, x) VALUES (1, 1);
INSERT INTO probe (id, x) VALUES (2, 2);

SELECT nonexistent_col FROM probe;
-- 2 rows, all NULL          <- expected ERROR 42703

SELECT count(*) FROM probe WHERE nonexistent_col = 1;
-- 0                         <- expected ERROR 42703; silently matches nothing

SELECT count(*) FROM probe WHERE nonexistent_col IS NULL;
-- 2                         <- silently matches everything

SELECT x FROM probe ORDER BY nonexistent_col;
-- rows in storage order     <- sort key silently ignored

UPDATE probe SET x = 99 WHERE nonexistent_col = 1;
-- UPDATE 0                  <- write silently no-ops

-- Fixed-schema engines fold identically:
CREATE COLLECTION probe_strict (a INT4 PRIMARY KEY, b INT8) WITH (engine = 'document_strict');
INSERT INTO probe_strict (a, b) VALUES (1, 2);
SELECT nonexistent_col FROM probe_strict;   -- 1 row, NULL  <- expected ERROR 42703

CREATE COLLECTION probe_kv (k TEXT PRIMARY KEY, v TEXT) WITH (engine = 'kv');
INSERT INTO probe_kv (k, v) VALUES ('a', '1');
SELECT nonexistent_col FROM probe_kv;       -- 1 row, NULL  <- expected ERROR 42703

Expected behavior

An identifier that names no column of any collection in scope raises 42703 (undefined_column) at plan time, in every clause (projection, WHERE, GROUP BY, ORDER BY, UPDATE SET/WHERE), matching PostgreSQL. For the document (schemaless) engine, a declared-schema collection knows its column set at plan time just as strict does; if resolving unknown identifiers to NULL is intended for genuinely schemaless reads, that intent cannot extend to document_strict/kv, whose schemas are closed.

Actual behavior

The unknown identifier is planned as a field reference and evaluates to NULL per row on every engine tested, including document_strict and kv. Predicates, sort keys, and write predicates built on the typo silently degrade: reads return wrong row sets, UPDATE/DELETE silently touch zero rows, and no error surfaces anywhere.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong — query results silently wrong; stored data intact
• The server crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (rewrite the query, avoid one path, etc.)

Proposed severity

SEV-2 — High: major functionality broken or silently-wrong results; stored data intact

Reproducibility

Always — every attempt

Last known-good version / commit (if a regression)

Unknown — likely never raised; the plan-time existence gate added for functions does not cover column references.

Environment & logs

Linux x86_64, release build from a fresh data directory, trust mode, pgwire via psql 16. No relevant server log lines — no error is produced anywhere on these paths.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on a released tag or a current main build (not a stale local branch).
• This is not a security vulnerability (those go to a private advisory).