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)
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
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 raising22012. 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
Expected behavior
22012raised 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)
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
mainbuild (not a stale local branch).