Skip to content

Expression errors fold silently over constant derived tables — 22012 raised on collection scans but not on FROM (SELECT ...) #295

Description

@emanzx

Version / build tested against

origin/main @ 2886155

Deployment mode

Origin — single node (local)

Engine(s) involved

Not engine-specific / unsure

Summary

Expression errors still fold silently when the query's FROM source is a constant derived table (FROM (SELECT 1 AS x) s). Division by zero in a projection, aggregate argument, GROUP BY key, or window PARTITION BY over such a derived table returns NULL rows or an empty result set with success, instead of raising 22012. The identical expressions over a real collection raise correctly — the earlier conversions of the aggregate/GROUP BY/window paths hold there — so the remaining hole is specific to the plan shape produced for constant subquery sources, which appears to pre-evaluate the expression on a path that still has the silent fallback. In the GROUP BY case a projected column is additionally dropped from the result set entirely.

Steps to reproduce

-- Constant scalar raises (correct):
SELECT 1/0;                                      -- ERROR: division by zero

-- Same expressions over a real collection raise (correct):
CREATE COLLECTION divp (id INT PRIMARY KEY, x INT);
INSERT INTO divp (id, x) VALUES (1, 1);
SELECT sum(x/0) FROM divp;                       -- ERROR: division by zero
SELECT x, count(*) FROM divp GROUP BY x/0;       -- ERROR: division by zero
SELECT sum(x) OVER (PARTITION BY x/0) FROM divp; -- ERROR: division by zero

-- Over a constant derived table, every one of them folds:
SELECT x/0 FROM (SELECT 1 AS x) s;
--  x / 0
-- -------
--
-- (1 row)          <- NULL, success; expected ERROR 22012

SELECT sum(x/0) FROM (SELECT 1 AS x) s;
-- 1 row, NULL      <- expected ERROR 22012

SELECT x, count(*) FROM (SELECT 1 AS x) s GROUP BY x/0;
-- (0 rows), and only the count(*) column is present in the result description
--                  <- expected ERROR 22012; also drops the projected x column

SELECT sum(x) OVER (PARTITION BY x/0) FROM (SELECT 1 AS x) s;
-- 1 row, NULL      <- expected ERROR 22012

-- The derived table itself is not the trigger — one that scans a collection raises:
SELECT sum(x/0) FROM (SELECT x FROM divp) s;     -- ERROR: division by zero

Expected behavior

22012 raised for division/modulus by zero regardless of the FROM source shape. A constant derived table is an optimization detail; error semantics should be identical to the collection-scan plan.

Actual behavior

With a values-only derived table as the source, the failing expression yields NULL (projection, aggregate, window) or an empty result set with a missing output column (GROUP BY), all with success status.

What actually happened? (check all that are true)

  • Acknowledged/committed data was lost, corrupted, or silently wrong — silently-wrong query results; 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-3 — Medium: feature wrong, but operational and a workaround exists

Reproducibility

Always — every attempt

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

Never worked, as far as tested — this is the remaining shape of the silent-expression-error class rather than a regression of the fixed paths.

Environment & logs

Linux x86_64, release build from a fresh data directory, trust mode, pgwire via psql 16. No relevant server log lines.

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:sqlParser, planner, SQL semanticspriority:P2Scheduled, not urgentsev:3-mediumFeature wrong, but operational and a workaround existsstatus:needs-triageAwaiting maintainer triage (severity + priority)type:bugA defect — broken, incorrect, or lost data

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions