@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/25.2-having-edge-cases.sqllogic

@@ -0,0 +1,318 @@
+-- adapted from SQLite test/having.test
+-- HAVING edge cases: predicates over aggregate results, multiple aggregates in
+-- one expression, NULL-aware predicates, and rejection of non-grouped columns.
+
+create table he (id integer primary key, grp text, val integer null);
+insert into he values
+  (1, 'a', 10),
+  (2, 'a', 20),
+  (3, 'b', null),
+  (4, 'b', null),
+  (5, 'c', 30),
+  (6, 'c', 40);
+
+-- HAVING with IS NULL on aggregate output
+-- Group 'b' has only NULL values, so min(val) is NULL
+select grp from he group by grp having min(val) is null order by grp;
+→ [{"grp":"b"}]
+
+-- HAVING with IS NOT NULL on aggregate
+select grp from he group by grp having min(val) is not null order by grp;
+→ [{"grp":"a"},{"grp":"c"}]
+
+-- HAVING comparing two aggregates
+-- For 'a': sum=30, avg=15 → sum > avg*2? 30 > 30 → false
+-- For 'c': sum=70, avg=35 → 70 > 70 → false
+-- (none qualify)
+select grp from he group by grp having sum(val) > avg(val) * 2 order by grp;
+→ []
+
+-- HAVING comparing two aggregates with strict inequality
+-- For 'a': sum=30 vs count(*)*5 = 10 → 30 > 10 true
+-- For 'b': sum=NULL vs count(*)*5 = 10 → NULL>10 false
+-- For 'c': sum=70 vs count(*)*5 = 10 → 70 > 10 true
+select grp from he group by grp having sum(val) > count(*) * 5 order by grp;
+→ [{"grp":"a"},{"grp":"c"}]
+
+-- HAVING uses an aggregate alias from the SELECT list
+select grp, sum(val) as total from he group by grp having total > 30 order by grp;
+→ [{"grp":"c","total":70}]
+
+-- HAVING with arithmetic on aggregates: average of squared sums per group
+-- (a's sum=30, b's sum=NULL → treated as no contribution, c's sum=70)
+select grp from he group by grp having sum(val) + count(*) > 35 order by grp;
+→ [{"grp":"c"}]
+
+-- HAVING that filters out the only candidate group
+select grp from he group by grp having sum(val) > 1000;
+→ []
+
+drop table he;
+
+-- =============================================================================
+-- HAVING referencing a non-grouped column should be rejected
+-- =============================================================================
+
+create table hu (id integer primary key, grp text, val integer);
+insert into hu values (1, 'a', 10), (2, 'a', 20);
+
+-- HAVING referencing a non-grouped, non-aggregated column (id) is rejected.
+select grp from hu group by grp having id > 0;
+-- error: id
+
+-- HAVING referencing a non-grouped column alongside an aggregate in SELECT.
+select grp, sum(val) from hu group by grp having val > 0;
+-- error: val
+
+-- HAVING with a mix of grouped and ungrouped columns is rejected for the
+-- ungrouped reference (the AND'd `grp` reference itself is fine).
+select grp, sum(val) from hu group by grp having grp = 'a' and val > 0;
+-- error: val
+
+-- HAVING over the implicit single group (no GROUP BY, aggregate in SELECT)
+-- may not reference bare columns.
+select count(*) from hu having id > 0;
+-- error: id
+
+-- Positive: HAVING with an aggregate is fine.
+select grp from hu group by grp having sum(val) > 0 order by grp;
+→ [{"grp":"a"}]
+
+-- Positive: HAVING with a GROUP BY column is fine.
+select grp from hu group by grp having grp = 'a';
+→ [{"grp":"a"}]
+
+-- Positive: HAVING references the same expression that appears in GROUP BY
+-- (fingerprint-match path). val=10 → 20, val=20 → 40; only `val=20` group qualifies.
+select val * 2 as v2 from hu group by val * 2 having val * 2 > 30 order by v2;
+→ [{"v2":40}]
+
+drop table hu;
+
+-- =============================================================================
+-- HAVING with bound parameters must resolve via the parameter scope
+-- =============================================================================
+
+create table hp (id integer, grp text, val integer);
+insert into hp values (1,'a',10),(2,'a',20),(3,'b',5),(4,'b',5);
+
+-- Anonymous ? parameter in HAVING: groups with count(*) matching the bound value.
+-- params: [2]
+select grp from hp group by grp having count(*) = ? order by grp;
+→ [{"grp":"a"},{"grp":"b"}]
+
+-- Named parameter in HAVING: groups whose sum exceeds the bound threshold.
+-- params: {"threshold":15}
+select grp from hp group by grp having sum(val) > :threshold order by grp;
+→ [{"grp":"a"}]
+
+-- Anonymous ? in both WHERE and HAVING: positional indexing must span clauses.
+-- WHERE keeps only val >= 10 (rows 1,2 → group 'a' count 2; group 'b' empty),
+-- then HAVING count(*) = 2 selects 'a'. Mirrors the original bug-report shape.
+-- params: [10, 2]
+select grp from hp where val >= ? group by grp having count(*) = ? order by grp;
+→ [{"grp":"a"}]
+
+drop table hp;
+
+-- =============================================================================
+-- HAVING with NO aggregate and NO GROUP BY
+--
+-- Such a query is still an aggregate query: it has one implicit group over all
+-- input rows, and HAVING filters that single group. It therefore yields at most
+-- one row, and every clause above the aggregation is subject to the usual
+-- coverage rule (only grouping columns — here, none — and aggregates).
+-- Regression: the clause used to be dropped from the plan entirely, so the
+-- query returned every input row unfiltered.
+-- =============================================================================
+
+create table hn (id integer primary key, grp text, val integer);
+insert into hn values (1, 'x', 10), (2, 'y', 20), (3, 'x', 30);
+
+create table hnempty (id integer primary key, val integer);
+
+-- A bare column above the aggregation is rejected: the implicit group carries no
+-- such column. The SELECT list is checked before HAVING is built, so when both name
+-- an ungrouped column the SELECT-list message is the one raised -- same order as a
+-- GROUP BY query, whose select list is checked at the same point.
+select grp from hn having grp = 'x';
+-- error: Column 'grp' must appear in the GROUP BY clause
+
+select * from hn having grp = 'x';
+-- error: Column 'id' must appear in the GROUP BY clause
+
+-- ...including when the HAVING predicate itself is a constant, so the only ungrouped
+-- reference is in the SELECT list.
+select grp from hn having 1 = 0;
+-- error: Column 'grp' must appear in the GROUP BY clause
+
+select * from hn having 1 = 1;
+-- error: Column 'id' must appear in the GROUP BY clause
+
+-- With a select list that carries no bare column, HAVING's own check is what fires,
+-- under its dedicated message.
+select 1 as one from hn having grp = 'x';
+-- error: HAVING references non-grouped column 'grp'
+
+-- A SELECT-list alias in HAVING is not a way around the rule: it denotes the same
+-- ungrouped column.
+select val as v from hn having v = 10;
+-- error: Column 'val' must appear in the GROUP BY clause
+
+-- Constant-true predicate keeps the single implicit group.
+select 1 as one from hn having 1 = 1;
+→ [{"one":1}]
+
+-- Constant-false predicate filters it out. (Before the fix this returned all
+-- three rows of `hn`.)
+select 1 as one from hn having 1 = 0;
+→ []
+
+-- The implicit group exists even over an empty table — aggregation over no rows
+-- still produces exactly one group.
+select 1 as one from hnempty having 1 = 1;
+→ [{"one":1}]
+
+select 1 as one from hnempty having 1 = 0;
+→ []
+
+-- A WHERE that removes every row does not remove the group either: WHERE runs below
+-- the aggregation, so the implicit group is still formed over the (now empty) input.
+select 1 as one from hn where val > 100 having 1 = 1;
+→ [{"one":1}]
+
+select 1 as one from hn where val > 15 having 1 = 1;
+→ [{"one":1}]
+
+-- A NULL predicate does not pass the filter, exactly as in WHERE.
+select 1 as one from hn having null;
+→ []
+
+-- The shape nested as a FROM-clause subquery: the outer query sees one row or none.
+select count(*) as c from (select 1 as one from hn having 1 = 1);
+→ [{"c":1}]
+
+select count(*) as c from (select 1 as one from hn having 1 = 0);
+→ [{"c":0}]
+
+-- ...and as an arm of a compound select.
+select 1 as one from hn having 1 = 0 union all select 2 as one from hn having 1 = 1;
+→ [{"one":2}]
+
+-- ...and as the source of an INSERT.
+create table hnsink (id integer primary key, v integer);
+insert into hnsink (id, v) select 1, 1 from hn having 1 = 0;
+select count(*) as c from hnsink;
+→ [{"c":0}]
+
+insert into hnsink (id, v) select 1, 1 from hn having 1 = 1;
+select count(*) as c from hnsink;
+→ [{"c":1}]
+
+drop table hnsink;
+
+-- A scalar subquery is a legal HAVING predicate here: it is not a bare column of
+-- the aggregated row.
+select 1 as one from hn having (select count(*) from hn) > 2;
+→ [{"one":1}]
+
+select 1 as one from hn having (select count(*) from hn) > 5;
+→ []
+
+-- Compositions above the aggregation: LIMIT, DISTINCT, ORDER BY.
+select 1 as one from hn having 1 = 1 limit 1;
+→ [{"one":1}]
+
+select distinct 1 as one from hn having 1 = 1;
+→ [{"one":1}]
+
+-- ORDER BY over an ungrouped aggregate query sorts the *input* rows below the
+-- aggregation (a documented Quereus extension), so naming `val` here is legal
+-- and the single output row is unaffected.
+select 1 as one from hn having 1 = 1 order by val;
+→ [{"one":1}]
+
+-- The same shape as a view body.
+create view hnv as select 1 as one from hn having 1 = 1;
+select * from hnv;
+→ [{"one":1}]
+
+drop view hnv;
+
+-- A HAVING inside a subquery may reference an *enclosing* query's column, exactly
+-- as WHERE may — that is a correlated outer reference, not an ungrouped local
+-- column, and the coverage check must still tell the two apart when the subquery
+-- has no aggregates at all.
+select h.val from hn h where exists (select 1 from hn t having h.grp = 'x') order by h.val;
+→ [{"val":10},{"val":30}]
+
+-- A window function over the implicit group runs over the *aggregated* row, not the
+-- input rows: there is exactly one, so `count(*) over ()` is 1. (Before the fix this
+-- ran over all three input rows and returned 3, three times.)
+select count(*) over () as c from hn having 1 = 1;
+→ [{"c":1}]
+
+-- ORDER BY by output ordinal and by select-list alias both resolve above the single
+-- aggregated row. (Before the fix each returned three rows.)
+select 1 as one from hn having 1 = 1 order by 1;
+→ [{"one":1}]
+
+select 1 as one from hn having 1 = 1 order by one;
+→ [{"one":1}]
+
+-- An ORDER BY may also name an AGGREGATE here. A HAVING makes this an aggregate
+-- query on its own, so `count(*)` is legal in its ORDER BY exactly as it is in the
+-- ORDER BY of a query that names an aggregate in its SELECT list -- the aggregate
+-- is collected into the AggregateNode for the post-aggregate sort and stripped by
+-- the final projection. (Before the fix, both the collection step and applyOrderBy
+-- asked "does this query name an aggregate?" instead of "is this an aggregate
+-- query?", so the aggregate was never collected and the sort key was rejected with
+-- "Aggregate function count not allowed in this context".)
+select 1 as one from hn having 1 = 1 order by count(*);
+→ [{"one":1}]
+
+-- ...with more than one sort-only aggregate, and one of a different function.
+select 1 as one from hn having 1 = 1 order by count(*), max(val);
+→ [{"one":1}]
+
+-- ...and mixed with the select-list alias, which resolves on the final projection
+-- while the aggregates resolve on the AggregateNode below it.
+select 1 as one from hn having 1 = 1 order by count(*), one;
+→ [{"one":1}]
+
+-- A HAVING that names an aggregate beside a column-free select list. The select
+-- list carries no base-table column, so nothing is uncovered and the query is a
+-- plain aggregate query whose single implicit group the predicate filters.
+select 1 as one from hn having count(*) > 1;
+→ [{"one":1}]
+
+select 1 as one from hn having count(*) > 5;
+→ []
+
+select 'label' as k from hn having count(*) > 1 order by count(*);
+→ [{"k":"label"}]
+
+-- ...and the same over an empty table, where the implicit group still exists but
+-- its count is 0.
+select 1 as one from hnempty having count(*) > 0;
+→ []
+
+select 1 as one from hnempty having count(*) = 0;
+→ [{"one":1}]
+
+-- Regression guards: adding an aggregate or a GROUP BY must not change any of the
+-- long-standing behaviour.
+select count(*) as c from hn having count(*) > 5;
+→ []
+
+select count(*) as c from hn having count(*) > 1;
+→ [{"c":3}]
+
+select grp, count(*) as c from hn group by grp having grp = 'x';
+→ [{"grp":"x","c":2}]
+
+select count(*) as c from hn where grp = 'x' having count(*) > 1;
+→ [{"c":2}]
+
+drop table hn;
+drop table hnempty;

package/test/logic/25.3-aggregate-isnull-empty.sqllogic

@@ -0,0 +1,16 @@
+-- adapted from SQLite test/notnull2.test
+-- IS NULL / IS NOT NULL evaluated under an aggregate over an empty NOT NULL
+-- table. SQLite allows a bare column beside an aggregate without GROUP BY (its
+-- "bare aggregate" mode, where the non-aggregate columns yield NULL on empty
+-- input). Quereus rejects it by design: an ungrouped aggregate query has one
+-- implicit group, which carries no base-table column, so `a` here is exactly as
+-- uncovered as it would be under a GROUP BY that omits it -- and gets the same
+-- message. A select-list item that references no column at all IS accepted
+-- beside an aggregate; see 25.5. `a is null` is not one of those.
+
+create table ag_t (a integer primary key, b text);
+
+select a is null as a_is_null, a is not null as a_is_not_null, count(*) as n from ag_t;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+drop table ag_t;

package/test/logic/25.4-groupby-fd-constant-empty.sqllogic

@@ -0,0 +1,55 @@
+-- 25.4-groupby-fd-constant-empty.sqllogic
+-- Regression: ruleGroupByFdSimplification must never drop *every* GROUP BY
+-- column. When all group columns are equality-pinned to constants
+-- (`where a = 0 and k = 6`), FD propagation gives each an empty-determinant FD
+-- (`{} -> col`), minimalCover drains the cover, and the rule used to rebuild the
+-- aggregate with an empty GROUP BY (a scalar aggregate). A scalar aggregate
+-- emits one all-NULL `count=0` row over an empty input; a grouped query must
+-- emit ZERO rows. Target: rule-groupby-fd-simplification.ts.
+
+create table t (id integer primary key, a integer, b integer, k integer);
+insert into t values (2, 3, 4, 2), (3, 7, 1, 9);
+
+-- Multi-column, constant-pinned, EMPTY match -> [] (the regression).
+-- Pre-fix this returned [{"a":null,"k":null,"c":0,"s":null}].
+select a, k, count(*) as c, sum(b) as s from t where a = 0 and k = 6 group by a, k;
+→ []
+
+-- Multi-column, constant-pinned, NON-EMPTY match -> exactly one group row.
+-- Row id=3 (a=7, b=1, k=9) is the only match. Confirms the bail leaves the
+-- non-empty result correct.
+select a, k, count(*) as c, sum(b) as s from t where a = 7 and k = 9 group by a, k;
+→ [{"a":7,"k":9,"c":1,"s":1}]
+
+-- Single-column control, EMPTY match -> [] (must stay correct; rule never fires
+-- for a one-column GROUP BY because of the `groupBy.length <= 1` early return).
+select k, count(*) as c, sum(a) as s from t where k = 6 group by k;
+→ []
+
+-- Mixed: one constant-pinned column (`a`, dropped via the `{} -> a` FD and
+-- re-emitted as MIN(a)) plus one free column (`b`, kept as the surviving group
+-- key). Confirmed by plan dump to rewrite to `group by b -> min(a), count(*)`.
+-- Over an EMPTY match (`a = 0` matches no row) the surviving key still gates row
+-- production, so the result is zero rows — the partial-drop path must not
+-- resurrect the spurious-row bug.
+select a, b, count(*) as c from t where a = 0 group by a, b;
+→ []
+
+drop table t;
+
+-- Partial-drop coverage: the guard must only trigger when ALL grouping columns
+-- would be dropped. Here `name` is functionally determined by the primary key
+-- `id`, so the rule legitimately drops `name` (re-emitting MIN(name)) while
+-- KEEPING `id` as the surviving group key.
+create table u (id integer primary key, name text, dept text);
+insert into u values (1, 'alice', 'eng'), (2, 'bob', 'sales');
+
+select id, name, count(*) as c from u group by id, name order by id;
+→ [{"id":1,"name":"alice","c":1},{"id":2,"name":"bob","c":1}]
+
+-- Same FD-simplifiable shape over an EMPTY match still yields zero rows: a
+-- surviving key (`id`) gates row production, so no spurious row appears.
+select id, name, count(*) as c from u where id = 99 group by id, name;
+→ []
+
+drop table u;

package/test/logic/25.5-ungrouped-aggregate-column-free-select-item.sqllogic

@@ -0,0 +1,196 @@
+-- =============================================================================
+-- An ungrouped aggregate query (aggregates in the SELECT list, no GROUP BY) has
+-- exactly ONE implicit group over all input rows. That group's row carries the
+-- aggregate results and nothing else -- no base-table column.
+--
+-- So the rule the SELECT list is checked against is "does this item reference a
+-- column of the query's input?", NOT "is this item an aggregate?":
+--
+--   * a column-free item -- a literal, an expression over literals, a call whose
+--     arguments are column-free, a `case` over aggregates, a scalar subquery --
+--     references nothing the implicit group lacks, and is ACCEPTED. That is
+--     standard SQL and what SQLite and PostgreSQL do.
+--   * a bare column reference is REJECTED, with the same message and source
+--     position a GROUP BY query gets when it omits the column. Quereus
+--     deliberately does not import SQLite's permissive "bare columns" rule,
+--     which picks an arbitrary row of the group.
+--
+-- Regression: every accepted query below used to fail with "Cannot mix aggregate
+-- and non-aggregate columns in SELECT list without GROUP BY", a blanket throw
+-- that never asked whether the item named a column.
+-- =============================================================================
+
+create table uac (id integer primary key, a text, n integer);
+insert into uac values (1, 'x', 10), (2, 'y', 20);
+
+create table uacempty (id integer primary key, a text);
+
+-- --- Accepted: column-free items beside an aggregate.
+
+-- a string literal
+select 'total' as label, count(*) as c from uac;
+→ [{"label":"total","c":2}]
+
+-- an integer literal
+select 1 as one, count(*) as c from uac;
+→ [{"one":1,"c":2}]
+
+-- an expression over literals only
+select 1 + 1 as two, count(*) as c from uac;
+→ [{"two":2,"c":2}]
+
+-- a function call whose arguments are column-free
+select abs(-1) as k, count(*) as c from uac;
+→ [{"k":1,"c":2}]
+
+-- NULL is column-free too
+select null as z, count(*) as c from uac;
+→ [{"z":null,"c":2}]
+
+-- a cast over a literal
+select cast(1 as text) as k, count(*) as c from uac;
+→ [{"k":"1","c":2}]
+
+-- an IN list over literals
+select 1 in (1, 2) as k, count(*) as c from uac;
+→ [{"k":true,"c":2}]
+
+-- a COLLATE over a literal
+select 'a' collate binary as k, count(*) as c from uac;
+→ [{"k":"a","c":2}]
+
+-- more than one column-free item, and the aggregate not written first
+select count(*) as c, 'a' as x, 'b' as y from uac;
+→ [{"c":2,"x":"a","y":"b"}]
+
+-- several aggregates alongside
+select 'summary' as label, count(*) as c, sum(n) as s, max(a) as m from uac;
+→ [{"label":"summary","c":2,"s":30,"m":"y"}]
+
+-- --- Accepted: items that read the AGGREGATE results rather than input columns.
+
+-- a `case` over an aggregate
+select case when count(*) > 1 then 'many' else 'few' end as k, count(*) as c from uac;
+→ [{"k":"many","c":2}]
+
+-- an arithmetic expression over an aggregate
+select count(*) * 10 as k, count(*) as c from uac;
+→ [{"k":20,"c":2}]
+
+-- --- Accepted: a scalar subquery is a relational subtree that resolves its own
+-- --- scope, so it references no column of THIS query's input.
+
+select (select count(*) from uac) as sub, count(*) as c from uac;
+→ [{"sub":2,"c":2}]
+
+-- a correlated-looking subquery that is in fact uncorrelated
+select (select max(n) from uac) as sub, sum(n) as s from uac;
+→ [{"sub":20,"s":30}]
+
+-- ...but a GENUINELY correlated subquery, one that reads an ungrouped column of
+-- THIS query, is rejected. The select-list walk stops at every relational child,
+-- so it does not catch this; the finished-plan check (assertGroupedPlanCoverage)
+-- is the one that does, and it reports the same message. This is the seam between
+-- "the walk skipped it" and "the item is truly column-free", and the two must not
+-- be confused.
+select (select count(*) from uac t where t.a = uac.a) as sub, count(*) as c from uac;
+-- error: Column 'uac.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+select (select count(*) from uac t where t.n > uac.n) as sub, count(*) as c from uac;
+-- error: Column 'uac.n' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- --- KNOWN DIVERGENCE: a reference to an ENCLOSING query's column is constant
+-- --- with respect to this query's implicit group, so it should be accepted here
+-- --- exactly as it is in `having` (see 25.2) and in `where`. It is not: the
+-- --- select-list walk flags any column reference its coverage set lacks, with no
+-- --- notion of which query the reference belongs to, so an outer reference is
+-- --- rejected as though it were an uncovered column of this query. SQLite accepts
+-- --- both queries below (the first yields `x`, `y`). Tracked as
+-- --- backlog/bug-outer-column-rejected-in-aggregate-select-list; these pins flip
+-- --- from `-- error:` to result rows when it lands. Not a regression -- the old
+-- --- blanket mixing throw rejected the ungrouped form too, and the GROUPED form
+-- --- (second query) has always been rejected.
+
+select a from uac where exists (select uac.a, count(*) from uac t);
+-- error: Column 'uac.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+select a from uac where exists (select uac.a, count(*) from uac t group by t.a);
+-- error: Column 'uac.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- --- Accepted: the column-free item survives the clauses that sit above the
+-- --- aggregation.
+
+select distinct 'k' as label, count(*) as c from uac;
+→ [{"label":"k","c":2}]
+
+select 'k' as label, count(*) as c from uac limit 1;
+→ [{"label":"k","c":2}]
+
+select 'k' as label, count(*) as c from uac limit 0;
+→ []
+
+select 'k' as label, count(*) as c from uac order by count(*);
+→ [{"label":"k","c":2}]
+
+select 'k' as label, count(*) as c from uac having count(*) > 1;
+→ [{"label":"k","c":2}]
+
+select 'k' as label, count(*) as c from uac having count(*) > 5;
+→ []
+
+-- --- Accepted: over an empty table the implicit group still exists, so the
+-- --- column-free item is emitted beside a zero count.
+
+select 'total' as label, count(*) as c from uacempty;
+→ [{"label":"total","c":0}]
+
+-- --- Accepted: nested spellings, where another ProjectNode wraps the query.
+
+select * from (select 'k' as label, count(*) as c from uac);
+→ [{"label":"k","c":2}]
+
+-- ...and as an arm of a compound select.
+select 'k' as label, count(*) as c from uac union all select 'j', count(*) from uac;
+→ [{"label":"k","c":2},{"label":"j","c":2}]
+
+-- --- REJECTED: a bare column reference. This is the distinction the check makes,
+-- --- and it must keep failing -- with the GROUP BY coverage message and the
+-- --- offending column's own source position, not a generic mixing complaint.
+
+select a, count(*) as c from uac;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- the column need not be written first
+select count(*) as c, a from uac;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- a column buried inside an otherwise column-free expression is still a column
+select 'p' || a as k, count(*) as c from uac;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- ...including under a function call
+select length(a) as k, count(*) as c from uac;
+-- error: Column 'a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- ...and inside a `case`
+select case when n > 1 then 'big' else 'small' end as k, count(*) as c from uac;
+-- error: Column 'n' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- a qualified spelling is the same column (the message echoes the spelling the
+-- user wrote, so it names `uac.a` here)
+select uac.a, count(*) as c from uac;
+-- error: Column 'uac.a' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- `select *` beside an aggregate expands to bare columns and is rejected on the
+-- first of them
+select *, count(*) as c from uac;
+-- error: Column 'id' must appear in the GROUP BY clause or be used in an aggregate function
+
+-- --- Non-regression: adding the GROUP BY that covers the column accepts it, and
+-- --- the column-free item rides along unchanged.
+
+select 'k' as label, a, count(*) as c from uac group by a order by a;
+→ [{"label":"k","a":"x","c":1},{"label":"k","a":"y","c":1}]
+
+drop table uac;
+drop table uacempty;