@quereus/quereus 4.20.0 → 4.20.2

package/test/logic/07.3-group-by-extras.sqllogic

@@ -0,0 +1,602 @@
+-- adapted from SQLite test/groupby.test
+-- GROUP BY ordinal positions, expression grouping, alias resolution, and
+-- combined with HAVING / ORDER BY in non-trivial shapes.
+
+create table gx (id integer primary key, grp text, sub text, val integer);
+insert into gx values
+  (1, 'a', 'x', 10),
+  (2, 'a', 'y', 20),
+  (3, 'b', 'x', 30),
+  (4, 'b', 'y', 40),
+  (5, 'a', 'x', 50);
+
+-- GROUP BY / ORDER BY positional ordinal references the Nth SELECT-list output
+select grp, count(*) as cnt from gx group by 1 order by 1;
+→ [{"grp":"a","cnt":3},{"grp":"b","cnt":2}]
+
+-- Multiple ordinals in GROUP BY and ORDER BY
+select grp, sub, sum(val) as total from gx group by 1, 2 order by 1, 2;
+→ [{"grp":"a","sub":"x","total":60},{"grp":"a","sub":"y","total":20},{"grp":"b","sub":"x","total":30},{"grp":"b","sub":"y","total":40}]
+
+-- Equivalent using explicit expressions
+select grp, count(*) as cnt from gx group by grp order by grp;
+→ [{"grp":"a","cnt":3},{"grp":"b","cnt":2}]
+
+-- GROUP BY mixed expression
+select grp || sub as combined, sum(val) as total
+from gx group by grp || sub order by grp || sub;
+→ [{"combined":"ax","total":60},{"combined":"ay","total":20},{"combined":"bx","total":30},{"combined":"by","total":40}]
+
+-- GROUP BY with arithmetic expression
+select val % 20 as bucket, count(*) as cnt
+from gx group by val % 20 order by val % 20;
+→ [{"bucket":0,"cnt":2},{"bucket":10,"cnt":3}]
+
+-- GROUP BY ordinal combined with HAVING — the resolved expression is the same
+-- plan node as the GROUP BY key, so HAVING still validates against that key.
+select grp, count(*) as cnt from gx group by 1 having count(*) > 2 order by 1;
+→ [{"grp":"a","cnt":3}]
+
+-- GROUP BY ordinal combined with ORDER BY ordinal on an aggregate output column
+select grp, sum(val) as total from gx group by 1 order by 2 desc;
+→ [{"grp":"a","total":80},{"grp":"b","total":70}]
+
+-- Equivalent using named columns
+select grp, count(*) as cnt from gx group by grp having count(*) > 2 order by grp;
+→ [{"grp":"a","cnt":3}]
+
+-- SELECT-list alias on a grouped column reference survives to the output and
+-- is available to ORDER BY.
+select grp as g, count(*) as cnt from gx group by grp order by g;
+→ [{"g":"a","cnt":3},{"g":"b","cnt":2}]
+
+-- Same with HAVING — alias still survives.
+select grp as g, count(*) as cnt from gx group by grp having count(*) > 0 order by g;
+→ [{"g":"a","cnt":3},{"g":"b","cnt":2}]
+
+-- Minimal repro: alias-only on a grouped column ref with no aggregates.
+select grp as g from gx group by grp order by g;
+→ [{"g":"a"},{"g":"b"}]
+
+-- A non-bare GROUP BY key is matched against the select list by an identity
+-- fingerprint that folds identifier case, so writing the same expression with
+-- different identifier casing still names the same key.
+select grp || sub as combined, count(*) as cnt
+from gx group by GRP || Sub order by combined;
+→ [{"combined":"ax","cnt":2},{"combined":"ay","cnt":1},{"combined":"bx","cnt":1},{"combined":"by","cnt":1}]
+
+-- Quoted literals are NOT case-folded by that fingerprint: `'-'` and the key's
+-- `'.'` differ, so the select-list expression is not the grouping key and the
+-- bare `grp` inside it is an ungrouped reference.
+select grp || '-' as combined from gx group by grp || '.';
+-- error: Column 'grp' must appear in the GROUP BY clause or be used in an aggregate function
+
+drop table gx;
+
+-- COLLATE NOCASE written in lowercase on a TEXT column is accepted at DDL (the
+-- name normalizes to canonical NOCASE), and GROUP BY / DISTINCT over that column
+-- honor the column's collation — case-variant values fold into a single group
+-- (unique-collation-name-case-insensitive-normalization).
+create table gn (id integer primary key, name text collate nocase, val integer);
+insert into gn values (1, 'Hello', 10), (2, 'HELLO', 20), (3, 'world', 5);
+
+-- GROUP BY folds 'Hello'/'HELLO' under NOCASE into one group. lower(name) keeps
+-- the assertion independent of which case-variant the engine picks as the group
+-- representative.
+select lower(name) as ln, count(*) as c, sum(val) as s from gn group by name order by ln;
+→ [{"ln":"hello","c":2,"s":30},{"ln":"world","c":1,"s":5}]
+
+-- count(distinct) honors the same collation: the two case-variants count as one.
+select count(distinct name) as n from gn;
+→ [{"n":2}]
+
+drop table gn;
+
+-- GROUP BY a CASE expression
+create table gc (id integer primary key, val integer);
+insert into gc values (1, 5), (2, 15), (3, 25), (4, 35), (5, 45);
+
+-- ORDER BY referencing an aggregate (count(*)) is allowed when the query has a GROUP BY.
+select case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end as bucket,
+       count(*) as cnt
+from gc group by case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end
+order by count(*) desc, case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end;
+→ [{"bucket":"low","cnt":2},{"bucket":"mid","cnt":2},{"bucket":"high","cnt":1}]
+
+-- Equivalent without aggregate in ORDER BY: sort by the GROUP BY expression
+select case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end as bucket,
+       count(*) as cnt
+from gc group by case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end
+order by case when val < 20 then 'low' when val < 40 then 'mid' else 'high' end;
+→ [{"bucket":"high","cnt":1},{"bucket":"low","cnt":2},{"bucket":"mid","cnt":2}]
+
+drop table gc;
+
+-- ORDER BY aggregate function — additional coverage
+create table aob (id integer primary key, grp text, val integer);
+insert into aob values
+  (1, 'a', 10), (2, 'a', 20), (3, 'a', 30),
+  (4, 'b', 40), (5, 'b', 50),
+  (6, 'c', 70);
+
+-- Scalar aggregate sorted by itself: single-row result.
+select count(*) as c from aob order by count(*);
+→ [{"c":6}]
+
+-- Baseline: ORDER BY alias of an aggregate in SELECT.
+select grp, sum(val) as s from aob group by grp order by s desc;
+→ [{"grp":"b","s":90},{"grp":"c","s":70},{"grp":"a","s":60}]
+
+-- Same result via explicit aggregate expression in ORDER BY.
+select grp, sum(val) as s from aob group by grp order by sum(val) desc;
+→ [{"grp":"b","s":90},{"grp":"c","s":70},{"grp":"a","s":60}]
+
+-- Aggregate referenced in ORDER BY only (not in SELECT).
+select grp from aob group by grp order by max(val) desc;
+→ [{"grp":"c"},{"grp":"b"},{"grp":"a"}]
+
+-- Negative: ORDER BY aggregate in a non-aggregate query is still rejected.
+select id from aob order by sum(val);
+-- error: Aggregate function sum not allowed in this context
+
+-- ...and a COLUMN-FREE select list does not change that. Such an item is legal
+-- beside an aggregate (see 25.5), but it is not itself an aggregate, so this query
+-- names no aggregate outside ORDER BY and is not an aggregate query. An aggregate
+-- written only in ORDER BY does not promote it into one -- same as SQLite, which
+-- answers "misuse of aggregate: count()". Add a HAVING (25.2) or select the
+-- aggregate to make the sort key legal.
+select 'k' from aob order by sum(val);
+-- error: Aggregate function sum not allowed in this context
+
+drop table aob;
+
+-- GROUP BY everything filtered out: no rows
+create table gf (id integer primary key, grp text, val integer);
+insert into gf values (1, 'a', 10), (2, 'b', 20);
+
+select grp, count(*) from gf where 1 = 0 group by grp;
+→ []
+
+drop table gf;
+
+-- ---------------------------------------------------------------------------
+-- GROUP BY two qualified columns that share a base name (i.id / c.id → `id`).
+-- Standard SQL allows this; it must group correctly rather than crash at plan
+-- time on a duplicate scope symbol.
+-- ---------------------------------------------------------------------------
+create table items (id integer primary key, name text, category_id integer);
+create table categories (id integer primary key, name text, type_id integer);
+create table log_entry_items (entry_id integer primary key, item_id integer);
+insert into items values (1, 'Widget', 100), (2, 'Gadget', 100), (3, 'Gizmo', 200);
+insert into categories values (100, 'Tools', 7), (200, 'Toys', 7);
+insert into log_entry_items values (10, 1), (11, 1), (12, 2);
+
+-- The exact reproduction from the ticket: two qualified same-base-name keys
+-- (`i.id`/`c.id`, `i.name`/`c.name`) group correctly; qualified SELECT columns
+-- resolve to their respective group keys. `usageCount` is 0 for the item with
+-- no log entries (count of a nullable left-join column).
+select i.id, i.name, c.id as categoryId, c.name as categoryName, count(lei.entry_id) as usageCount
+from items i
+join categories c on c.id = i.category_id
+left join log_entry_items lei on lei.item_id = i.id
+where c.type_id = ?
+group by i.id, i.name, c.id, c.name
+order by i.id;
+-- params: [7]
+→ [{"id":1,"name":"Widget","categoryId":100,"categoryName":"Tools","usageCount":2},{"id":2,"name":"Gadget","categoryId":100,"categoryName":"Tools","usageCount":1},{"id":3,"name":"Gizmo","categoryId":200,"categoryName":"Toys","usageCount":0}]
+
+-- Qualified reference in ORDER BY resolves to the group key (bare `id` would be
+-- ambiguous, but the qualifier disambiguates).
+select i.id as itemId, c.id as catId, count(*) as n
+from items i join categories c on c.id = i.category_id
+group by i.id, c.id
+order by c.id, i.id;
+→ [{"itemId":1,"catId":100,"n":1},{"itemId":2,"catId":100,"n":1},{"itemId":3,"catId":200,"n":1}]
+
+-- Qualified reference in HAVING resolves to the group key.
+select i.id as itemId, c.id as catId
+from items i join categories c on c.id = i.category_id
+group by i.id, c.id
+having i.id >= 2
+order by i.id;
+→ [{"itemId":2,"catId":100},{"itemId":3,"catId":200}]
+
+-- Two same-base-name columns projected unqualified-but-aliased → distinct output
+-- columns, no crash.
+select i.id as a, c.id as b, count(*) as n
+from items i join categories c on c.id = i.category_id
+group by i.id, c.id
+order by i.id;
+→ [{"a":1,"b":100,"n":1},{"a":2,"b":100,"n":1},{"a":3,"b":200,"n":1}]
+
+-- Degenerate duplicate key `group by i.id, i.id` (same column twice) must not
+-- crash; the qualified key still resolves.
+select i.id as itemId, count(*) as n
+from items i
+group by i.id, i.id
+order by i.id;
+→ [{"itemId":1,"n":1},{"itemId":2,"n":1},{"itemId":3,"n":1}]
+
+-- Negative: a genuinely ambiguous *bare* reference (HAVING `id` with two `id`
+-- group keys) raises the clear ambiguity error rather than crashing or silently
+-- binding to one source column.
+select i.id as itemId, c.id as catId
+from items i join categories c on c.id = i.category_id
+group by i.id, c.id
+having id >= 0;
+-- error: ambiguous column name: id
+
+-- Regression: single-table `group by c.id, c.name` (distinct base names) still
+-- works and resolves qualified references.
+select c.id, c.name, count(*) as n
+from categories c
+group by c.id, c.name
+order by c.id;
+→ [{"id":100,"name":"Tools","n":1},{"id":200,"name":"Toys","n":1}]
+
+drop table items;
+drop table categories;
+drop table log_entry_items;
+
+-- ---------------------------------------------------------------------------
+-- HAVING / ORDER BY aggregate matching by canonical AST fingerprint, not a
+-- shallow argument peek (bug-aggregate-reuse-matching-ignores-arguments).
+--
+-- A clause above the AggregateNode (HAVING, a top-level ORDER BY) that spells
+-- out an aggregate must only bind to the SELECT list's computed column when the
+-- argument expressions actually match; a differently-shaped argument must be
+-- collected and computed as its own aggregate instead.
+-- ---------------------------------------------------------------------------
+create table wg (a text, b text);
+insert into wg values ('x','1'),('y','2'),('x','3');
+
+-- Fixed: HAVING spells a *different* aggregate (`sum(a+0)`) than the SELECT
+-- list's `sum(b+0)`. `sum(a+0)` is 0 for every group, so no group qualifies.
+select a, sum(b+0) as s from wg group by a having sum(a+0) > 3;
+→ []
+
+-- Fixed: same divergence in ORDER BY. `sum(a+0)` is 0 for every group, so the
+-- sort is a no-op and rows keep source (group-discovery) order.
+select a, sum(b+0) as s from wg group by a order by sum(a+0);
+→ [{"a":"x","s":4},{"a":"y","s":2}]
+
+-- Control: identical spelling (`count(*)`) still reads the computed column.
+select a, count(*) as c from wg group by a having count(*) > 1;
+→ [{"a":"x","c":2}]
+
+-- Control: DISTINCT participates in the match — `count(distinct b)` is its own
+-- aggregate, matched by its own spelling.
+select a, count(distinct b) as cd from wg group by a having count(distinct b) > 1;
+→ [{"a":"x","cd":2}]
+
+-- Control: a SELECT-list alias reference resolves through the aggregate output
+-- scope, not through this matching at all.
+select a, sum(b) as s from wg group by a having s > 3;
+→ [{"a":"x","s":4}]
+
+-- Control: whitespace and redundant parentheses don't defeat the match — the
+-- fingerprint normalizes them.
+select a, sum(b+0) as s from wg group by a having sum(b + 0) > 3;
+→ [{"a":"x","s":4}]
+
+select a, sum(b) as s from wg group by a having sum((b)) > 3;
+→ [{"a":"x","s":4}]
+
+-- Control: identifier case doesn't defeat the match.
+select a, sum(B) as s from wg group by a having sum(b) > 3;
+→ [{"a":"x","s":4}]
+
+-- Narrowing (documented, not fixed): a qualifier divergence (`w.b` vs bare `b`)
+-- no longer matches, so HAVING computes a second, redundant aggregate over the
+-- same column instead of reusing the SELECT list's — the answer is unaffected.
+select a, sum(w.b) as s from wg w group by a having sum(b) > 3;
+→ [{"a":"x","s":4}]
+
+-- ---------------------------------------------------------------------------
+-- HAVING may name a GROUPING KEY by the SELECT-list alias of the column that
+-- selects it, just as it can name an aggregate by its alias (the control above).
+-- Both are ordinary output columns of the grouped query and both are registered
+-- in the aggregate output scope
+-- (bug-window-spec-cannot-name-group-key-by-select-alias).
+-- ---------------------------------------------------------------------------
+
+select a as k, count(*) as c from wg group by a having k = 'x';
+→ [{"k":"x","c":2}]
+
+-- A COMPUTED grouping key's alias resolves too — the select-list column is
+-- matched to its key by expression identity rather than by attribute.
+select upper(a) as k, count(*) as c from wg group by upper(a) having k = 'X';
+→ [{"k":"X","c":2}]
+
+-- The alias reaches inside a SUBQUERY in the predicate, where it correlates back to
+-- the grouping key. Two rows have a='x', one has a='y'.
+select a as k, count(*) as c from wg group by a having (select count(*) from wg t where t.a = k) > 1;
+→ [{"k":"x","c":2}]
+
+-- Beside an aggregate alias, both resolving through the same scope.
+select a as k, sum(b) as s from wg group by a having k = 'x' and s > 3;
+→ [{"k":"x","s":4}]
+
+-- DELIBERATE: the alias SHADOWS a same-named base-table column. `b` is a real
+-- column of `wg`, but in HAVING the alias wins and `b` is the grouping key `a`.
+-- Same rule an aggregate alias already had.
+select a as b, count(*) as c from wg group by a having b = 'x';
+→ [{"b":"x","c":2}]
+
+-- DELIBERATE, the other way: an alias is the LOWEST-precedence name in that
+-- scope and does not outrank a GROUPING KEY of the same name. `b` is both the
+-- alias of the `a` key and a grouping key here; HAVING `b = '1'` filters on the
+-- grouping key (one row survives), not on the alias (which would match nothing).
+select a as b, count(*) as c from wg group by a, b having b = '1';
+→ [{"b":"x","c":1}]
+
+-- Two aliases naming DIFFERENT grouping keys collide, and nothing in the scope
+-- can arbitrate, so a bare reference to the shared name is ambiguous.
+select a as k, b as k, count(*) as c from wg group by a, b having k = 'x';
+-- error: ambiguous column name: k
+
+-- The SELECT list itself is NOT widened by any of this: a select-list column
+-- still cannot name a sibling's alias, aggregate or grouping key alike. It is
+-- built against the pre-aggregate scope, before the aggregate output scope exists.
+select a, count(*) as c, c + 0 as d from wg group by a;
+-- error: Column not found: c
+
+select a as k, k as k2 from wg group by a;
+-- error: Column not found: k
+
+-- A quoted alias may contain a dot, which the scope's flat string key cannot tell
+-- apart from the qualified spelling of a grouping key. The alias is skipped rather
+-- than registered, so `"wg.a"` here is the grouping key `wg.a` and the query plans
+-- as it did before aliases were registered at all
+-- (bug-scope-symbol-keys-collide-with-dotted-column-names owns the underlying
+-- flat-key collision).
+select wg.a as "wg.a", count(*) as c from wg group by wg.a having "wg.a" = 'x';
+→ [{"wg.a":"x","c":2}]
+
+-- Same skip when the dotted alias names a DIFFERENT key than the qualified spelling
+-- it collides with: HAVING filters on the grouping key `a`, not on the alias of `b`.
+select wg.b as "wg.a", count(*) as c from wg group by wg.a, wg.b having "wg.a" = 'x';
+→ [{"wg.a":"1","c":1},{"wg.a":"3","c":1}]
+
+-- An alias whose grouping key came from a GROUP BY ORDINAL resolves like any other.
+select a as k, count(*) as c from wg group by 1 having k = 'x';
+→ [{"k":"x","c":2}]
+
+-- An alias colliding with a bare group-key name that is ALREADY ambiguous stays
+-- ambiguous — the skip leaves the existing marking untouched rather than resolving
+-- the name to the alias's key.
+select i.a as a, count(*) as c from wg i join wg c on i.a = c.a group by i.a, c.a having a = 'x';
+-- error: ambiguous column name: a
+
+-- A VIEW body is planned the same way, so a grouping-key alias works there too.
+create view vw_key_alias as select a as k, count(*) as c from wg group by a having k = 'x';
+
+select k, c from vw_key_alias;
+→ [{"k":"x","c":2}]
+
+drop view vw_key_alias;
+
+-- ---------------------------------------------------------------------------
+-- A subquery's HAVING may name a column of the ENCLOSING query
+-- (bug-having-rejects-correlated-outer-column).
+--
+-- The grouped-query restriction HAVING enforces is about THIS query's own
+-- ungrouped columns. A correlated reference out to the surrounding query is a
+-- different query's column and is legal in `having` exactly as it is in `where`.
+-- ---------------------------------------------------------------------------
+
+-- The inner HAVING compares a grouping key against the enclosing row's column.
+select w.b, (select count(*) from wg t group by t.a having t.a = w.a) as c
+from wg w order by w.b;
+→ [{"b":"1","c":2},{"b":"2","c":1},{"b":"3","c":2}]
+
+-- Same, with the enclosing column compared against one of the inner aggregates.
+-- Counts per group are x=2, y=1, so the group that survives differs per outer row.
+select w.b, (select count(*) from wg t group by t.a having count(*) = w.b + 0) as c
+from wg w order by w.b;
+→ [{"b":"1","c":1},{"b":"2","c":2},{"b":"3","c":null}]
+
+-- Same again, with the enclosing column on the LEFT of the comparison and a
+-- non-count aggregate on the right.
+select w.b, (select count(*) from wg t group by t.a having w.a = max(t.a)) as c
+from wg w order by w.b;
+→ [{"b":"1","c":2},{"b":"2","c":1},{"b":"3","c":2}]
+
+-- Same, in a HAVING with no GROUP BY at all (implicit single group).
+select w.b, (select count(*) from wg t having count(*) = 3 and w.b = '2') as c
+from wg w order by w.b;
+→ [{"b":"1","c":null},{"b":"2","c":3},{"b":"3","c":null}]
+
+-- Control: for comparison, the same correlation in WHERE, which always worked.
+select w.b, (select count(*) from wg t where t.a = w.a group by t.a) as c
+from wg w order by w.b;
+→ [{"b":"1","c":2},{"b":"2","c":1},{"b":"3","c":2}]
+
+-- Negative, grouped: the inner query's OWN ungrouped column keeps its rejection.
+select w.b, (select count(*) from wg t group by t.a having t.b = '1') as c from wg w;
+-- error: HAVING references non-grouped column 'b'
+
+-- Negative, no GROUP BY: same restriction, same message — pinned in full here, so
+-- the "may only reference" tail is asserted somewhere and not just the prefix.
+select w.b, (select count(*) from wg t having t.b = '1') as c from wg w;
+-- error: HAVING references non-grouped column 'b'; HAVING may only reference GROUP BY columns or aggregate expressions
+
+-- Correlating TWO levels out of a HAVING, not just one.
+select o.b, (select count(*) from wg m where m.b = o.b
+             and (select count(*) from wg t group by t.a having t.a = o.a) > 0) as c
+from wg o order by o.b;
+→ [{"b":"1","c":1},{"b":"2","c":1},{"b":"3","c":1}]
+
+-- The ENCLOSING query is itself grouped, and the inner HAVING names its GROUPING KEY.
+select w.a, count(*) as n, (select count(*) from wg t group by t.a having t.a = w.a) as c
+from wg w group by w.a order by w.a;
+→ [{"a":"x","n":2,"c":2},{"a":"y","n":1,"c":1}]
+
+-- Same shape, but the inner HAVING names an UNGROUPED column of the enclosing grouped
+-- query. HAVING's own check cannot see it (`w.b` is not one of the INNER query's
+-- pre-grouping columns), so it is the enclosing query's finished-plan check that
+-- rejects it, with the general wording rather than HAVING's dedicated message.
+select w.a, count(*) as n, (select count(*) from wg t group by t.a having t.a = w.b) as c
+from wg w group by w.a;
+-- error: Column 'w.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- The `skipSubqueries` contract: an ungrouped column of THIS query reached through a
+-- subquery inside HAVING is left to the finished-plan check, so it raises the general
+-- message and not HAVING's. This is the entire reason that parameter exists.
+select a, count(*) as c from wg group by a
+having (select max(t.a) from wg t where t.a = wg.b) = 'x';
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- ---------------------------------------------------------------------------
+-- An aggregate query with NO GROUP BY gets the same finished-plan check
+-- (bug-no-group-by-aggregate-skips-subquery-coverage-check).
+--
+-- Such a query has exactly one implicit group, so every clause ABOVE the
+-- aggregation — HAVING, an ORDER BY forced up there, LIMIT, OFFSET — may read
+-- only the aggregate results. Reading a source column instead is the same user
+-- error the grouped form already reports, and now reports the same way.
+-- ---------------------------------------------------------------------------
+
+-- HAVING, subquery correlating back to an ungrouped column of THIS query. The
+-- `group by a` twin directly below raises the identical message; before the fix
+-- this one silently answered off an arbitrary source row (returning []).
+select count(*) as c from wg
+having (select max(t.a) from wg t where t.b = wg.b) = 'x';
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a, count(*) as c from wg group by a
+having (select max(t.a) from wg t where t.b = wg.b) = 'x';
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- ORDER BY, once a select-list alias or an aggregate has forced the whole list
+-- above the aggregation. Both spellings of the forcing term are pinned.
+select count(*) as c from wg order by c, (select max(t.a) from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select count(*) as c from wg order by count(*), (select max(t.a) from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- LIMIT / OFFSET. These reached the runtime before the fix and died there with an
+-- engine-internal "No row context found for column b" the user could not act on;
+-- these cases pin the conversion to the plan-time message.
+select count(*) as c from wg limit b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select count(*) as c from wg limit (select count(*) from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+select count(*) as c from wg limit 1 offset (select count(*) from wg t where t.b = wg.b);
+-- error: Column 'wg.b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- The grouped twin of the LIMIT case, which always reported at plan time.
+select a, count(*) as c from wg group by a limit b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Positives — the check must not over-reject. A subquery reading only its OWN
+-- columns is not a reference to this query at all.
+select count(*) as c from wg having (select max(t.a) from wg t) = 'y';
+→ [{"c":3}]
+
+select count(*) as c from wg having (select max(t.a) from wg t) = 'zz';
+→ []
+
+-- A correlated reference to an ENCLOSING query, made from an ungrouped inner
+-- aggregate and buried one subquery deeper still. `w.b` belongs to the outer
+-- query, so the inner query's check leaves it alone. max(u.a) per outer b is
+-- 'x','y','x', so only b='2' fails the comparison.
+select w.b, (select count(*) from wg t
+             having (select max(u.a) from wg u where u.b = w.b) = 'x') as c
+from wg w order by w.b;
+→ [{"b":"1","c":3},{"b":"2","c":null},{"b":"3","c":3}]
+
+select count(*) as c from wg order by count(*);
+→ [{"c":3}]
+
+select count(*) as c from wg order by (select max(t.a) from wg t);
+→ [{"c":3}]
+
+select count(*) as c from wg limit (select count(*) from wg t);
+→ [{"c":3}]
+
+-- The documented pre-aggregate-sort extension stays legal. With no GROUP BY and
+-- no term naming an alias or an aggregate, the whole ORDER BY sorts the INPUT
+-- rows before aggregation, so a correlated subquery in it is evaluated once per
+-- input row and is well defined. That sort sits BELOW the aggregate, which is
+-- where the finished-plan walk stops. Asserted in both directions so the
+-- ordering is observable rather than incidental.
+select group_concat(b) as g from wg
+order by (select max(t.b) from wg t where t.b = wg.b) desc;
+→ [{"g":"3,2,1"}]
+
+select group_concat(b) as g from wg
+order by (select max(t.b) from wg t where t.b = wg.b) asc;
+→ [{"g":"1,2,3"}]
+
+-- DISTINCT above the implicit single group is unaffected either way.
+select distinct count(*) as c from wg order by c;
+→ [{"c":3}]
+
+-- A VIEW body is planned the same way, so the mistake is caught at `create view`
+-- time rather than at first read of the view.
+create view vw_ungrouped_limit as select count(*) as c from wg limit b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- Same for a MATERIALIZED VIEW body, which takes a different creation path.
+create materialized view mvw_ungrouped_limit as select count(*) as c from wg limit b;
+-- error: Column 'b' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- EXISTS is another spelling of the correlated-subquery mistake — the walk is
+-- about the reference, not about the subquery being scalar.
+select count(*) as c from wg having exists (select 1 from wg t where t.a = wg.a);
+-- error: Column 'wg.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- LIMIT is newly covered by the check, so the shape it must NOT reject is pinned
+-- too: an ungrouped aggregate SUBQUERY whose LIMIT correlates OUT to the
+-- enclosing query. `w.a` is the enclosing query's column, not this one's.
+select w.a, (select count(*) from wg t
+             limit (select count(*) from wg u where u.a = w.a)) as c
+from wg w order by w.a;
+→ [{"a":"x","c":3},{"a":"x","c":3},{"a":"y","c":3}]
+
+-- Compound and VALUES-fed ungrouped aggregates keep working: each arm is planned
+-- as its own aggregate query, and neither reads anything above its aggregation.
+select count(*) as c from wg union all select count(*) from wg;
+→ [{"c":3},{"c":3}]
+
+select count(*) as c from (values ('x'),('y'));
+→ [{"c":2}]
+
+drop table wg;
+
+-- ---------------------------------------------------------------------------
+-- HAVING / ORDER BY aggregate matching folds identifier case only, not literal
+-- case (bug-aggregate-match-ignores-string-literal-case). A quoted string
+-- literal's case is part of an aggregate's identity: two aggregates that differ
+-- only in literal case (`nullif(b,'A')` vs `nullif(b,'a')`) must never collapse
+-- into one, or a clause above the AggregateNode silently reads the wrong number.
+-- ---------------------------------------------------------------------------
+create table wgl (id integer primary key, g integer, b text);
+insert into wgl values
+  (1, 1, 'A'), (2, 1, 'A'), (3, 1, 'a'),
+  (4, 2, 'A'), (5, 2, 'a'), (6, 2, 'a');
+
+-- Fixed: HAVING spells a literal-case-distinct aggregate (`nullif(b,'a')`) from
+-- the SELECT list's `nullif(b,'A')`; HAVING binds to its own aggregate rather
+-- than reusing (and reporting) the SELECT list's.
+select g, count(nullif(b,'A')) as c from wgl where g = 1 group by g having count(nullif(b,'a')) > 1;
+→ [{"g":1,"c":1}]
+
+-- Same shape, both aggregates present in the SELECT list: HAVING must bind to
+-- `d`, not silently reuse `c`.
+select g, count(nullif(b,'A')) as c, count(nullif(b,'a')) as d from wgl where g = 1 group by g having count(nullif(b,'a')) > 1;
+→ [{"g":1,"c":1,"d":2}]
+
+-- Fixed: same divergence in a top-level ORDER BY, using two groups so a wrong
+-- bind changes row order (not just a displayed value). Ordering by
+-- count(nullif(b,'a')) (g=1 → 2, g=2 → 1) puts g=2 first; the buggy fold would
+-- instead have ordered by the SELECT list's count(nullif(b,'A')) (g=1 → 1,
+-- g=2 → 2), putting g=1 first.
+select g, count(nullif(b,'A')) as c from wgl group by g order by count(nullif(b,'a'));
+→ [{"g":2,"c":2},{"g":1,"c":1}]
+
+drop table wgl;