@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/07.3.1-group-by-order-by-key.sqllogic

@@ -0,0 +1,164 @@
+-- ORDER BY a GROUP BY key in a grouped query whose SELECT list contains no
+-- aggregate function at all.
+--
+-- Regression for bug-order-by-group-key-not-in-select-list: the planner used to
+-- decide the final-projection path from "does the SELECT list contain an
+-- aggregate function" rather than "did a grouping phase run". A `group by` with
+-- no aggregate anywhere therefore took *both* paths and emitted a second,
+-- stale projection whose column references still pointed at pre-aggregate
+-- attributes. A bare-column `order by` over a grouping key inserted a blocking
+-- Sort underneath that stale projection, the source row context was gone by the
+-- time it ran, and the query failed with "No row context found for column v".
+-- Adding any aggregate (`count(*)`) or sorting by the output alias hid the bug.
+--
+-- The rule pinned here: any expression legal in GROUP BY is legal in ORDER BY of
+-- the same query and sorts by the grouped value, regardless of how — or
+-- whether — the SELECT list projects it.
+--
+-- Plan shape (exactly one Project, Sort above it) is asserted separately in
+-- test/plan/grouped-projection-shape.spec.ts; this file pins the results.
+
+create table gk (v integer primary key, g text);
+insert into gk values (1,'a'),(2,'b'),(3,'a');
+
+-- The original repro: grouping key wrapped in an expression in the SELECT list,
+-- ORDER BY names the bare key.
+select cast(v as text) x from gk group by v order by v;
+→ [{"x":"1"},{"x":"2"},{"x":"3"}]
+
+-- DESC behaves the same.
+select cast(v as text) x from gk group by v order by v desc;
+→ [{"x":"3"},{"x":"2"},{"x":"1"}]
+
+-- Arithmetic instead of CAST.
+select v+0 x from gk group by v order by v;
+→ [{"x":1},{"x":2},{"x":3}]
+
+-- Function call over a text grouping key.
+select upper(g) x from gk group by g order by g;
+→ [{"x":"A"},{"x":"B"}]
+
+select upper(g) x from gk group by g order by g desc;
+→ [{"x":"B"},{"x":"A"}]
+
+-- Bare grouping key in the SELECT list (no expression wrapper, still no aggregate):
+-- output keeps the SELECT-list name, not the raw group column.
+select g from gk group by g order by g;
+→ [{"g":"a"},{"g":"b"}]
+
+-- ORDER BY an *expression over* a grouping key.
+select cast(v as text) x from gk group by v order by -v;
+→ [{"x":"3"},{"x":"2"},{"x":"1"}]
+
+-- HAVING over a grouping key combined with the bare-column ORDER BY.
+select cast(v as text) x from gk group by v having v > 1 order by v;
+→ [{"x":"2"},{"x":"3"}]
+
+select upper(g) x from gk group by g having g > 'a' order by g;
+→ [{"x":"B"}]
+
+-- DISTINCT over the projected expression.
+select distinct upper(g) x from gk group by g order by g;
+→ [{"x":"A"},{"x":"B"}]
+
+-- LIMIT / OFFSET above the sort.
+select upper(g) x from gk group by g order by g limit 1;
+→ [{"x":"A"}]
+
+select cast(v as text) x from gk group by v order by v limit 1 offset 1;
+→ [{"x":"2"}]
+
+-- Multiple grouping keys, ORDER BY both as bare columns.
+select cast(v as text) x from gk group by g, v order by g, v;
+→ [{"x":"1"},{"x":"3"},{"x":"2"}]
+
+-- Grouping key projected both bare and wrapped.
+select g, upper(g) x from gk group by g order by g;
+→ [{"g":"a","x":"A"},{"g":"b","x":"B"}]
+
+-- Contrast: the same shape *with* an aggregate always worked; it must keep working.
+select cast(v as text) x, count(*) c from gk group by v order by v;
+→ [{"x":"1","c":1},{"x":"2","c":1},{"x":"3","c":1}]
+
+-- Contrast: the non-grouped path still applies ORDER BY before the projection
+-- (this is what `shouldApplyOrderByBeforeProjection` exists for) — 'a' appears
+-- twice because there is no grouping here.
+select upper(g) x from gk order by g;
+→ [{"x":"A"},{"x":"A"},{"x":"B"}]
+
+-- ---------------------------------------------------------------------------
+-- SELECT * / bare column list over a grouped query.
+-- The forced final projection must emit *source-column* order (v, g), not
+-- GROUP BY order (g, v). Column order itself is asserted in the plan-shape spec
+-- (row objects compare key-order-insensitively here); these cases pin that each
+-- name still carries its own column's value.
+-- ---------------------------------------------------------------------------
+select v, g from gk group by g, v order by v;
+→ [{"v":1,"g":"a"},{"v":2,"g":"b"},{"v":3,"g":"a"}]
+
+select * from gk group by g, v order by v;
+→ [{"v":1,"g":"a"},{"v":2,"g":"b"},{"v":3,"g":"a"}]
+
+select gk.* from gk group by v, g order by v;
+→ [{"v":1,"g":"a"},{"v":2,"g":"b"},{"v":3,"g":"a"}]
+
+-- Two stars in one grouped SELECT list. Each expands once: replaying every
+-- expanded star column for each star emitted the whole set N times over.
+create table gj (k integer primary key, w text);
+insert into gj values (1,'p'),(2,'q'),(3,'r');
+
+select gk.*, gj.* from gk join gj on gk.v = gj.k group by gk.v, gk.g, gj.k, gj.w order by v;
+→ [{"v":1,"g":"a","k":1,"w":"p"},{"v":2,"g":"b","k":2,"w":"q"},{"v":3,"g":"a","k":3,"w":"r"}]
+
+drop table gj;
+
+-- ---------------------------------------------------------------------------
+-- The grouped, aggregate-free select must compose everywhere a relation can go.
+-- ---------------------------------------------------------------------------
+
+-- As a derived table, re-sorted by the outer query.
+select x from (select upper(g) x from gk group by g order by g) order by x desc;
+→ [{"x":"B"},{"x":"A"}]
+
+-- As a CTE.
+with c as (select upper(g) x from gk group by g order by g) select * from c;
+→ [{"x":"A"},{"x":"B"}]
+
+-- As an IN subquery.
+select v from gk where v in (select v from gk group by v order by v) order by v;
+→ [{"v":1},{"v":2},{"v":3}]
+
+-- As a scalar subquery.
+select (select upper(g) from gk where v = 1 group by g) s;
+→ [{"s":"A"}]
+
+-- As a compound-select branch.
+select upper(g) x from gk group by g union all select 'z';
+→ [{"x":"A"},{"x":"B"},{"x":"z"}]
+
+-- As a materialized view body.
+create materialized view mvg as select g from gk group by g;
+select g from mvg order by g;
+→ [{"g":"a"},{"g":"b"}]
+
+drop materialized view mvg;
+drop table gk;
+
+-- ---------------------------------------------------------------------------
+-- NULL grouping key. NULLs collapse into one group and the bare-column ORDER BY
+-- places them per the explicit NULLS clause (the *default* placement under DESC
+-- is deliberately not asserted — see 10.5.3-desc-index-ordering).
+-- ---------------------------------------------------------------------------
+create table gkn (v integer primary key, g text null);
+insert into gkn values (1,'a'),(2,null),(3,'b'),(4,null);
+
+select upper(g) x from gkn group by g order by g nulls first;
+→ [{"x":null},{"x":"A"},{"x":"B"}]
+
+select upper(g) x from gkn group by g order by g nulls last;
+→ [{"x":"A"},{"x":"B"},{"x":null}]
+
+select upper(g) x from gkn group by g order by g desc nulls last;
+→ [{"x":"B"},{"x":"A"},{"x":null}]
+
+drop table gkn;

package/test/logic/07.3.2-grouped-select-list-shape.sqllogic

@@ -0,0 +1,231 @@
+-- A grouped query returns exactly the columns in its SELECT list, in SELECT-list
+-- order — nothing more, and not in GROUP BY order.
+--
+-- Regression for bug-grouped-aggregate-only-select-returns-extra-column. An
+-- AggregateNode advertises every grouping key it computes followed by its
+-- aggregate results, so whenever the planner skipped the final projection the
+-- query's declared result shape became the aggregate's shape rather than the
+-- select list's: `select count(*) from t group by g` handed back `g` as well as
+-- the count, and a select list that named its keys in a different order than
+-- GROUP BY got them back in GROUP BY order. The projection is now skipped only
+-- when the two shapes already agree column for column.
+--
+-- Column *names and order* are asserted in test/plan/grouped-projection-shape.spec.ts
+-- (row objects compare key-order-insensitively here); this file pins the values.
+
+create table t (v integer primary key, g text null);
+insert into t values (1,'a'),(2,null),(3,'b'),(4,null);
+
+-- The original repro: select list is only an aggregate, so the grouping key must
+-- not appear at all.
+select count(*) as n from t group by g;
+→ [{"n":1},{"n":2},{"n":1}]
+
+select sum(v) s from t group by g;
+→ [{"s":1},{"s":6},{"s":3}]
+
+-- Unaliased aggregate keeps its expression name and stays the only column.
+select count(*) from t group by g;
+→ [{"count(*)":1},{"count(*)":2},{"count(*)":1}]
+
+-- HAVING attached does not reintroduce the key.
+select count(*) as n from t group by g having count(*) > 1;
+→ [{"n":2}]
+
+-- ORDER BY over the (unselected) grouping key still sorts by it.
+select count(*) as n from t group by g order by g nulls first;
+→ [{"n":2},{"n":1},{"n":1}]
+
+-- Contrast: the scalar-aggregate (no GROUP BY) case was always correct.
+select count(*) n from t;
+→ [{"n":4}]
+
+-- Contrast: naming the key keeps it, exactly once.
+select g, count(*) c from t group by g order by g nulls first;
+→ [{"g":null,"c":2},{"g":"a","c":1},{"g":"b","c":1}]
+
+drop table t;
+
+-- ---------------------------------------------------------------------------
+-- SELECT-list order, independent of GROUP BY order. No primary key, so the
+-- functional-dependency GROUP BY reduction cannot rewrite the grouping keys out
+-- from under these cases.
+-- ---------------------------------------------------------------------------
+create table nk (a text, b text);
+insert into nk values ('x','1'),('y','2');
+create table u (z text);
+insert into u values ('p'),('q');
+
+-- Aggregate first, grouping key after it.
+select count(*) c, a from nk group by a order by a;
+→ [{"c":1,"a":"x"},{"c":1,"a":"y"}]
+
+-- Keys named in the reverse of GROUP BY order.
+select b, a, count(*) c from nk group by a, b order by a;
+→ [{"b":"1","a":"x","c":1},{"b":"2","a":"y","c":1}]
+
+-- Aggregate interleaved between two grouping keys.
+select a, count(*) c, b from nk group by a, b order by a;
+→ [{"a":"x","c":1,"b":"1"},{"a":"y","c":1,"b":"2"}]
+
+-- Fewer keys named than grouped on.
+select count(*) c from nk group by a, b order by a;
+→ [{"c":1},{"c":1}]
+
+-- Qualified reference to a bare grouping key is the same column.
+select nk.a, count(*) c from nk group by a order by a;
+→ [{"a":"x","c":1},{"a":"y","c":1}]
+
+-- SELECT * over a grouped query with an aggregate: source-column order, then the
+-- aggregate.
+select *, count(*) c from nk group by a, b order by a;
+→ [{"a":"x","b":"1","c":1},{"a":"y","b":"2","c":1}]
+
+-- Grouped/ungrouped agreement: a mixed select list (named columns plus a star,
+-- no aggregate) assembles star position the same way whether or not the query
+-- is grouped — the ungrouped path (buildFinalProjections) and the grouped path
+-- (buildFinalAggregateProjections) must agree. `group by a, b` collapses no
+-- rows here (a, b together are already unique), so the two queries return the
+-- same shape and values.
+select b, a, * from nk order by a;
+→ [{"b":"1","a":"x","a:1":"x","b:1":"1"},{"b":"2","a":"y","a:1":"y","b:1":"2"}]
+
+select b, a, * from nk group by a, b order by a;
+→ [{"b":"1","a":"x","a:1":"x","b:1":"1"},{"b":"2","a":"y","a:1":"y","b:1":"2"}]
+
+-- Two aggregates and no named key: still no key in the output.
+select count(*) c1, count(distinct b) c2 from nk group by a order by c1;
+→ [{"c1":1,"c2":1},{"c1":1,"c2":1}]
+
+-- A grouping key named twice is emitted twice — the select list is one column
+-- shorter than the aggregate output here, the opposite of the leaked-key case.
+select a, a, count(*) c from nk group by a order by a;
+→ [{"a":"x","a:1":"x","c":1},{"a":"y","a:1":"y","c":1}]
+
+-- An aggregate inside a scalar subquery aggregates over the *other* table, so it
+-- is a non-aggregate item of this query and must not claim an aggregate slot.
+select (select count(*) from u) su, count(*) c from nk group by a order by a;
+→ [{"su":2,"c":1},{"su":2,"c":1}]
+
+-- The aggregate-only grouped select composes as a derived table...
+select n from (select count(*) n from nk group by a) order by n;
+→ [{"n":1},{"n":1}]
+
+-- ...as a CTE...
+with c as (select count(*) n from nk group by a) select * from c;
+→ [{"n":1},{"n":1}]
+
+-- ...and as a materialized view body, where the reordered projection must still
+-- carry the grouping key through as the view's unique key.
+create materialized view mvn as select count(*) n, a from nk group by a;
+select n, a from mvn order by a;
+→ [{"n":1,"a":"x"},{"n":1,"a":"y"}]
+
+drop materialized view mvn;
+
+-- Contrast: an aggregate-only body has no grouping key in its output, so it is
+-- genuinely unkeyed and a materialized view rejects it. Before the projection was
+-- built the leaked grouping key made this body look keyed by accident.
+create materialized view mvbad as select count(*) n from nk group by a;
+-- error: materialized view 'main.mvbad' body produces duplicate rows
+
+drop table u;
+drop table nk;
+
+-- ---------------------------------------------------------------------------
+-- The select list survives the FD-driven GROUP BY simplification.
+--
+-- `rule-groupby-fd-simplification` drops a grouping column that another grouping
+-- column functionally determines and re-emits it as a picker `min(<col>)`. An
+-- aggregate's layout is fixed — grouping keys first, then aggregate results — so
+-- the dropped column leaves the key block for the aggregate block. Each select
+-- list below already agrees with the *pre-rewrite* aggregate shape, so no
+-- projection is built above the aggregate and it is the query root: the shift
+-- used to reach the result (bug-grouped-key-reorder-survives-to-output).
+--
+-- Column order is asserted in test/plan/grouped-projection-shape.spec.ts (row
+-- objects compare key-order-insensitively here); this file pins the values, so a
+-- picker that recovered the wrong value per group would fail here.
+-- ---------------------------------------------------------------------------
+
+-- Primary-key-driven: `v` determines `g`, so `g` is dropped and re-picked.
+create table pk (v integer primary key, g text);
+insert into pk values (1,'a'),(2,'b'),(3,'a');
+
+select g, v, count(*) c from pk group by g, v order by v;
+→ [{"g":"a","v":1,"c":1},{"g":"b","v":2,"c":1},{"g":"a","v":3,"c":1}]
+
+drop table pk;
+
+-- Equality-driven: `where a = b` puts the two grouping columns in one equivalence
+-- class, so either one determines the other.
+create table eqk (a text, b text);
+insert into eqk values ('x','x'),('y','z'),('w','w');
+
+select a, b, count(*) c from eqk where a = b group by a, b order by a;
+→ [{"a":"w","b":"w","c":1},{"a":"x","b":"x","c":1}]
+
+drop table eqk;
+
+-- Join-equality-driven, with the dropped column in the middle of the select list.
+create table jl (a text, b text);
+create table jr (a text, c text);
+insert into jl values ('x','1'),('y','2');
+insert into jr values ('x','p'),('y','q');
+
+select jl.a, jl.b, jr.a, jr.c, count(*) c from jl join jr on jl.a = jr.a
+  group by jl.a, jl.b, jr.a, jr.c order by jl.a;
+→ [{"a":"x","b":"1","a:1":"x","c":"p","c:1":1},{"a":"y","b":"2","a:1":"y","c":"q","c:1":1}]
+
+drop table jl;
+drop table jr;
+
+-- The same two same-named keys with NO dependency between them (the join is on
+-- the *other* pair of columns), so the FD simplification does not fire and
+-- nothing caps the aggregate: it is the query root itself. Its own output names
+-- must still be disambiguated the way a projection's are — a result row is
+-- keyed by column name, so a repeated `a` drops one of the two values
+-- (bug-duplicate-aggregate-output-names-collapse-row). The memory and store
+-- modules pick different plans here, so this pins both physical aggregates.
+create table dl (a text, b text);
+create table dr (a text, c text);
+insert into dl values ('x','p'),('y','q');
+insert into dr values ('m','p'),('n','q');
+
+select dl.a, dr.a, count(*) n from dl join dr on dl.b = dr.c group by dl.a, dr.a order by dl.a;
+→ [{"a":"x","a:1":"m","n":1},{"a":"y","a:1":"n","n":1}]
+
+drop table dl;
+drop table dr;
+
+-- `insert into … select` binds the select output by POSITION, so it is the
+-- consumer the reorder actually corrupted: with the shift, `g`'s text landed in
+-- `sink.v` and `v`'s integer in `sink.g`.
+create table src (v integer primary key, g text);
+insert into src values (1,'a'),(2,'b');
+create table sink (g text, v integer, c integer);
+
+insert into sink select g, v, count(*) from src group by g, v;
+select g, v, c from sink order by v;
+→ [{"g":"a","v":1,"c":1},{"g":"b","v":2,"c":1}]
+
+-- A `union` arm is the other positional consumer: arms are matched column by
+-- position, and the union's column names come from the first arm. With the shift,
+-- the grouped arm contributed (v, g, c) — pairing integers against the literal
+-- arm's text and vice versa.
+select g, v, count(*) c from src group by g, v
+union all
+select 'z', 9, 1
+order by v;
+→ [{"g":"a","v":1,"c":1},{"g":"b","v":2,"c":1},{"g":"z","v":9,"c":1}]
+
+-- Grouped arm second: the union's column names now come from the literal arm, so
+-- a shifted grouped arm would silently file its values under the wrong names.
+select 'z' g, 9 v, 1 c
+union all
+select g, v, count(*) from src group by g, v
+order by v;
+→ [{"g":"a","v":1,"c":1},{"g":"b","v":2,"c":1},{"g":"z","v":9,"c":1}]
+
+drop table sink;
+drop table src;

package/test/logic/07.4-group-by-filter-composite-pk.sqllogic

@@ -0,0 +1,120 @@
+-- Regression: streaming aggregate must not leak a yielded group's
+-- representative-row context across the next child pull.
+--
+-- A grouped StreamAggregate yields the just-finished group with that group's
+-- representative SOURCE row installed in the runtime context (for HAVING /
+-- correlated reads / projection). Those descriptors are built from the source's
+-- attribute IDs — the SAME IDs a streaming child Filter publishes for its own
+-- row. If the aggregate leaves them live while it pulls the next input row, the
+-- Filter directly below resolves its predicate columns through the aggregate's
+-- STALE representative row instead of the child's current row, so the WHERE
+-- predicate is evaluated against the wrong values and effectively dropped.
+--
+-- Shape that triggers it (StreamAggregate, no interposed Sort, standalone Filter
+-- directly below):
+--   * composite PK (d, r) so the IndexScan is already ordered for GROUP BY d
+--     => StreamAggregate is chosen with no Sort (a Sort would drain the child),
+--   * filter on a non-leading PK column (r) absent from GROUP BY => cannot seek,
+--     => the predicate stays a standalone Filter node right under the aggregate.
+--
+-- Without the fix, the row pulled immediately AFTER a group boundary is filtered
+-- against the previous group's stale representative row, so a row that should be
+-- dropped is wrongly folded into the new group.
+
+create table bt (d integer, r integer, total integer null, primary key (d, r));
+insert into bt values
+  (1, 10, 150),
+  (1, 20, null),
+  (2, 10, 7),
+  (2, 20, 3),
+  (3, 10, 1),
+  (3, 20, 99);
+
+-- PRIMARY BUG: equality filter on the non-leading composite-PK column.
+-- d=2 is the tell: only (2,10,7) matches r=10, so sum is 7 (NOT 7+3=10).
+-- d=3 likewise: only (3,10,1) matches, so sum is 1 (NOT 1+99=100).
+-- d=1 reads 150 either way (its dropped row (1,20,null) contributes null to sum).
+select d, sum(total) as s from bt where r = 10 group by d order by d;
+→ [{"d":1,"s":150},{"d":2,"s":7},{"d":3,"s":1}]
+
+-- RANGE filter (no constant-pin / attributeDefaults surface): same expected rows,
+-- proving the fix is not specific to the r=const shape.
+select d, sum(total) as s from bt where r > 9 and r < 11 group by d order by d;
+→ [{"d":1,"s":150},{"d":2,"s":7},{"d":3,"s":1}]
+
+-- count(*) catches the wrong-keep directly: under the bug d=2/d=3 would each see
+-- a second (wrongly-kept) row. Correct count is 1 per group. count(col) likewise.
+select d, count(*) as c, count(total) as ct from bt where r = 10 group by d order by d;
+→ [{"d":1,"c":1,"ct":1},{"d":2,"c":1,"ct":1},{"d":3,"c":1,"ct":1}]
+
+-- DISTINCT aggregate under the same shape — exercises the per-group distinct-tree
+-- reset adjacent to the edited code. A wrongly-kept post-boundary row would inflate
+-- the distinct sum (d=2 -> 10, d=3 -> 100). Correct values match sum(total).
+select d, sum(distinct total) as sd from bt where r = 10 group by d order by d;
+→ [{"d":1,"sd":150},{"d":2,"sd":7},{"d":3,"sd":1}]
+
+-- HAVING over the filtered rollup — confirms the representative-row context is still
+-- readable during the yield, and the filtered sums feed HAVING correctly. Only d=1
+-- exceeds 100 once the bug-kept rows are excluded.
+select d, sum(total) as s from bt where r = 10 group by d having sum(total) > 100 order by d;
+→ [{"d":1,"s":150}]
+
+-- DROPPED-FIRST-ROW-OF-A-LATER-GROUP: filter r=20 keeps (1,20,null),(2,20,3),(3,20,99).
+-- Under the bug the boundary's stale r=20 wrongly passes (3,10,1) (whose real r=10
+-- should be dropped), inflating d=3 to 100. Correct d=3 is 99. d=1 is null (its only
+-- kept row has total null) — also exercises sum-over-all-null.
+select d, sum(total) as s from bt where r = 20 group by d order by d;
+→ [{"d":1,"s":null},{"d":2,"s":3},{"d":3,"s":99}]
+
+-- ORDER BY downstream of the aggregate (desc): consumer reads aggregate output
+-- after the generator resumes; must stay correct and ordered.
+select d, sum(total) as s from bt where r = 10 group by d order by d desc;
+→ [{"d":3,"s":1},{"d":2,"s":7},{"d":1,"s":150}]
+
+-- Empty result / zero matching rows.
+select d, sum(total) as s from bt where r = 99 group by d order by d;
+→ []
+
+-- CONTROL: scalar aggregate (no GROUP BY) — separate code branch, never interleaved
+-- with a yielded-group context. 150 + 7 + 1 = 158.
+select sum(total) as s from bt where r = 10;
+→ [{"s":158}]
+
+-- CONTROL: plain projection (no aggregate at all) — the Filter standing alone must
+-- still reject the r=20 rows. Locks that the filter itself is correct.
+select d, r, total from bt where r = 10 order by d;
+→ [{"d":1,"r":10,"total":150},{"d":2,"r":10,"total":7},{"d":3,"r":10,"total":1}]
+
+drop table bt;
+
+-- CONTROL: single-column-PK analogue. Filtering on the PK column (k) is a seek, so
+-- there is NO standalone Filter under the aggregate — the interleaving hazard cannot
+-- arise. Must remain correct.
+create table sp (k integer primary key, total integer);
+insert into sp values (1, 10), (2, 20), (3, 30);
+
+select k, sum(total) as s from sp where k >= 2 group by k order by k;
+→ [{"k":2,"s":20},{"k":3,"s":30}]
+
+drop table sp;
+
+-- CONTROL: HashAggregate path. With PK on id, GROUP BY d is unsorted, so the planner
+-- picks HashAggregate (it drains the child fully before yielding any group, so no
+-- interleaving). Same logical query as the primary case — assert it stays correct,
+-- don't assume. ORDER BY d makes the (unordered) hash output deterministic.
+create table ht (id integer primary key, d integer, r integer, total integer null);
+insert into ht values
+  (1, 1, 10, 150),
+  (2, 1, 20, null),
+  (3, 2, 10, 7),
+  (4, 2, 20, 3),
+  (5, 3, 10, 1),
+  (6, 3, 20, 99);
+
+select d, sum(total) as s from ht where r = 10 group by d order by d;
+→ [{"d":1,"s":150},{"d":2,"s":7},{"d":3,"s":1}]
+
+select d, count(*) as c, sum(total) as s from ht where r = 20 group by d order by d;
+→ [{"d":1,"c":1,"s":null},{"d":2,"c":1,"s":3},{"d":3,"c":1,"s":99}]
+
+drop table ht;

package/test/logic/07.5-sum-mixed-exact-and-float.sqllogic

@@ -0,0 +1,151 @@
+-- 07.5-sum-mixed-exact-and-float.sqllogic
+-- Regression: sum() over a column mixing exact integers with floating-point values.
+--
+-- sum() keeps TWO accumulator slots and never mixes the two number domains until
+-- finalize: a bigint or safe-integer number joins the exact part, everything else
+-- (fractions, whole numbers past the safe-integer boundary, non-finites) joins the
+-- floating-point part. Before that split, one slot decided per addition whether the
+-- running total was exact or float, which
+--   (a) silently dropped values (a fractional side made BigInt() throw and the step
+--       swallowed it),
+--   (b) turned a REAL column's total into an arbitrary-precision integer, and
+--   (c) made the answer depend on the order rows happened to be scanned.
+--
+-- Every fold-order pair below must agree — that equality, not just the literal
+-- expected value, is what this file is guarding.
+--
+-- NOTE: the two fold orders are forced with `order by id` inside a subquery, and
+-- nothing here asserts that the two scans genuinely ran in opposite orders. If the
+-- planner ever becomes free to discard an inner `order by` that no outer clause
+-- observes, these arms weaken to two identical scans and stop guarding anything —
+-- they would still pass. If that optimization lands, pin the orders some other way
+-- (an ordered plan assertion under test/plan/, or scan-order-sensitive data).
+
+-- ===========================================================================
+-- 1. Fraction + integer past the safe-integer boundary — both scan orders
+-- ===========================================================================
+
+create table sum_mixed (id integer primary key, v numeric);
+insert into sum_mixed values (1, 0.5), (2, 9007199254740993);
+-- run
+
+-- Ascending: the fraction arrives first. Used to return 0.5 (the large value vanished).
+select sum(v) as s, typeof(sum(v)) as ty from sum_mixed;
+→ [{"s":9007199254740992,"ty":"integer"}]
+
+-- Descending: the large value arrives first. Used to return 9007199254740993.
+select sum(v) as s from (select v from sum_mixed order by id desc);
+→ [{"s":9007199254740992}]
+
+-- Fold-order independence stated directly, not inferred from two literals matching.
+select (select sum(v) from (select v from sum_mixed order by id asc))
+     = (select sum(v) from (select v from sum_mixed order by id desc)) as same;
+→ [{"same":true}]
+
+-- Anchored to binary `+` over the same pair — the engine's rule for one mixed
+-- addition, which sum's routing now mirrors.
+select sum(v) = 9007199254740993 + 0.5 as matches_binary_plus from sum_mixed;
+→ [{"matches_binary_plus":true}]
+
+-- ===========================================================================
+-- 2. Three values: two fractions and one large integer
+-- ===========================================================================
+-- Used to return 0.75 — the large value dropped and both fractions survived.
+
+create table sum_three (id integer primary key, v numeric);
+insert into sum_three values (1, 0.5), (2, 0.25), (3, 9007199254740993);
+-- run
+
+select sum(v) as s from sum_three;
+→ [{"s":9007199254740992}]
+
+select sum(v) as s from (select v from sum_three order by id desc);
+→ [{"s":9007199254740992}]
+
+-- ===========================================================================
+-- 3. A whole `number` outside the safe-integer range is NOT exact
+-- ===========================================================================
+-- 1e308 is a legal `number` (R1 constrains which values may be bigint, not which
+-- numbers may be whole). Routing it to the exact part is what produced a 309-digit
+-- integer total for a REAL column — a bigint in a REAL result, violating R2.
+
+create table sum_real (id integer primary key, v real);
+insert into sum_real values (1, 1e308), (2, 0.5);
+-- run
+
+select sum(v) as s, typeof(sum(v)) as ty from sum_real;
+→ [{"s":1e308,"ty":"integer"}]
+
+select sum(v) as s from (select v from sum_real order by id desc);
+→ [{"s":1e308}]
+
+select sum(v) = 0.5 + 1e308 as matches_binary_plus from sum_real;
+→ [{"matches_binary_plus":true}]
+
+-- ===========================================================================
+-- 4. A REAL total that overflows to infinity
+-- ===========================================================================
+-- Used to return a 309-digit exact integer with typeof 'integer'. It now stays in
+-- the float domain and agrees with total(), the other float-summing aggregate.
+-- (Infinity has no JSON spelling, so this section asserts through text and equality.)
+
+create table sum_overflow (id integer primary key, v real);
+insert into sum_overflow values (1, 1e308), (2, 1e308);
+-- run
+
+select typeof(sum(v)) as ty, cast(sum(v) as text) as txt from sum_overflow;
+→ [{"ty":"real","txt":"Infinity"}]
+
+select sum(v) = total(v) as agrees_with_total from sum_overflow;
+→ [{"agrees_with_total":true}]
+
+-- ===========================================================================
+-- 5. Unchanged: all-integer and all-float folds
+-- ===========================================================================
+
+-- An all-integer fold still accumulates exactly, promoting and narrowing under R1.
+create table sum_ints (id integer primary key, v integer);
+insert into sum_ints values (1, 9007199254740991), (2, 5), (3, -6);
+-- run
+
+-- Promotes past 2^53−1 mid-fold, then retracts back inside it.
+select sum(v) as s, typeof(sum(v)) as ty from sum_ints;
+→ [{"s":9007199254740990,"ty":"integer"}]
+
+-- A total that stays outside the safe range remains exact.
+delete from sum_ints where id = 3;
+select sum(v) as s from sum_ints;
+→ [{"s":9007199254740996}]
+
+-- An all-float fold is bit-identical to plain left-to-right float addition.
+create table sum_floats (id integer primary key, v real);
+insert into sum_floats values (1, 0.1), (2, 0.2);
+-- run
+
+select sum(v) = 0.1 + 0.2 as same from sum_floats;
+→ [{"same":true}]
+
+-- Empty group and all-NULL group still finalize to NULL.
+create table sum_nulls (id integer primary key, v numeric null);
+insert into sum_nulls values (1, null), (2, null);
+-- run
+
+select sum(v) as s from sum_nulls;
+→ [{"s":null}]
+
+select sum(v) as s from sum_nulls where id > 99;
+→ [{"s":null}]
+
+-- ===========================================================================
+-- 6. GROUP BY keeps the split per group
+-- ===========================================================================
+
+create table sum_grouped (id integer primary key, g text, v numeric);
+insert into sum_grouped values
+  (1, 'exact', 9007199254740993), (2, 'exact', 5),
+  (3, 'mixed', 9007199254740993), (4, 'mixed', 0.5),
+  (5, 'float', 0.5), (6, 'float', 0.25);
+-- run
+
+select g, sum(v) as s, typeof(sum(v)) as ty from sum_grouped group by g order by g;
+→ [{"g":"exact","s":9007199254740998,"ty":"integer"},{"g":"float","s":0.75,"ty":"real"},{"g":"mixed","s":9007199254740992,"ty":"integer"}]