Skip to content

fix(sql): raise expression errors over constant derived tables - #321

Closed
EnRaiha wants to merge 6 commits into
mainfrom
fix/issue295-derived-tables
Closed

fix(sql): raise expression errors over constant derived tables#321
EnRaiha wants to merge 6 commits into
mainfrom
fix/issue295-derived-tables

Conversation

@EnRaiha

@EnRaiha EnRaiha commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Problem

Expression errors fold silently when the query's FROM source is a constant derived table (FROM (SELECT 1 AS x) s). Division by zero returns NULL instead of raising 22012.

Fix

Three commits:

  1. raise expression errors over constant derived tables
  2. carry window specs through derived-table post-processing
  3. fix window functions over scan-bodied derived tables

Test Results

  • derived_expression_errors: 6 passed
  • sql_window_functions: 64 passed
  • Total: 122 passed, 0 failed

Fixes #295

…ng them

Outer projections and aggregate/group-key arguments over a constant
derived table used to fold silently: the CTE body materialized as bare
value rows, the response shaper found no computed alias and emitted NULL,
and aggregates over the body scanned an empty collection. Computed
projection expressions now ride on the materialized-row scans as computed
columns and evaluate per row (division raises 22012, sequence accessors
raise 0A000); aggregates whose input is a non-Scan body lower it to a
ProviderScan sub-plan so the accumulator receives the rows and evaluates
its arguments and group keys against them.

Window functions over a constant derived table are still folded silently;
that path needs window evaluation in the row post-processor and is
tracked separately.
… them per row

The derived-table tail now transports window function specs from the
outer query all the way to the materialized-row scan, which evaluates
each spec per partition after computed columns. Partition, ordering,
and argument errors fail the query instead of answering NULL.

The subquery fold and validation walks now cover window expressions,
so catalog casts inside window clauses fold and validate like every
other expression on the wrapper.
inline_cte merges an outer SELECT's constraints onto a derived body
when that body is itself a Scan, and it copied the BODY's (empty)
window list in place of the OUTER's — so SUM/row_number/rank over
FROM (SELECT * FROM c) silently answered NULL on every row. The
outer window specs now run after the body's own, matching the
post-processor branch, and two positive-value tests lock in the
carriage and the results.
Copilot AI lite review requested due to automatic review settings September 10, 2026 15:23

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@EnRaiha EnRaiha changed the title fix(sql): raise expression errors over constant derived tables [DRAFT] fix(sql): raise expression errors over constant derived tables Sep 10, 2026
@EnRaiha EnRaiha changed the title [DRAFT] fix(sql): raise expression errors over constant derived tables fix(sql): raise expression errors over constant derived tables Sep 10, 2026
Remove '(issue #295 Gap 3)' references from four comment locations.
Refine each comment to be professional and jargon-free while
preserving the technical explanation of why window specs must be
evaluated after computed columns over derived tables.
4 files still had stale (issue #295) references missed in previous
cleanup pass — aggregate/plan.rs, set_ops.rs, provider_scan.rs,
derived_expression_errors.rs module doc.
@EnRaiha EnRaiha closed this Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants