Repository navigation
sql: aggregation without GROUP BY is rejected #817
Description
Activity
Scope grilling transcript
Q: Should this fix support an omitted
GROUP BYat every aggregation level the parser already supports—including nested SQL subqueries—or only the single-layer queries explicitly called out in issue 817?A: "i dont mind fixing both, what would be the output obtained from these in terms of the internal data structure that we are using to store parsed things?"
Q: Does that distinction make sense, and do you want nested queries treated as a required outcome for this issue or explicitly out of scope?
A: "the current SQL execution path appears to support only some nested patterns -- yes that's true
We can add support for nested queries while parsing, but adding pattern matching for them and execution support, we can defer. I think some other issues may cover it (confirm pls)"Confirmed: #819 tracks nested SQL aggregation matching/planning/execution. This issue changes parsing only for nested shapes.
Q: Should all currently recognized aggregates without
GROUP BYbecome supported—SUM,COUNT(column),MIN,MAX,QUANTILE, andCOUNT(DISTINCT column)—whileAVGremains unsupported for its existing independent single-statistic execution limitation?A: "yes"
Q: Should we preserve the existing SQL validity rule that a global aggregate may select only aggregate expressions?
A: "sure"
Q: Should an explicit empty grouping clause be treated the same as omitted grouping?
A: "yea"
Implementation note: The bundled SQL dialect rejects
GROUP BY ()beforeSQLPatternParserreceives an AST.Q: Should I keep #817 narrowly scoped to an omitted
GROUP BY—the issue's original syntax—or expand it to add a SQL-rewrite/parser workaround forGROUP BY ()?A: "yeah makes sense."
Resolved scope:
- Parse an omitted
GROUP BYas an empty grouping-label set at outer and innerSELECTlevels. - Support one-layer global
SUM,COUNT(column),MIN,MAX,QUANTILE, andCOUNT(DISTINCT column)through planning and execution-context construction. - Preserve existing rejection of
AVG,COUNT(*), arithmetic or multi-aggregate projections, missing time ranges, ungrouped non-aggregate projections, and nested matching/execution. - Add parser regressions for global grouping labels and support-runner coverage for affected one-layer queries.
- Keep
GROUP BY ()out of scope because the upstream dialect parser rejects it.
- Parse an omitted
- linked a pull request that will close this issuefix(sql-parser): accept global aggregates without GROUP BY #826
on Oct 11, 2026
Problem
A SQL aggregation without a
GROUP BYclause is rejected, even though it is a single-layer query with a valid time range. The planner fails withSQL parse error: Failed to parse SQL query: ....Equivalent PromQL:
sum(sum_over_time(data[5m]))This affects every global aggregate:
SUM,COUNT,MIN,MAX,QUANTILE,COUNT(DISTINCT col). The same queries withGROUP BY <label>are supported.More examples:
SELECT QUANTILE(0.5, value) FROM quantile_wide WHERE time BETWEEN DATEADD(s, -1, NOW()) AND NOW()quantile(0.5, quantile_wide)SELECT SUM(value) FROM data WHERE time BETWEEN DATEADD(s, -1, NOW()) AND NOW()sum(data)SELECT QUANTILE(0.95, value) FROM order_service_http_request_duration_seconds WHERE time BETWEEN DATEADD(s, -300, NOW()) AND NOW()histogram_quantile(0.95, sum by (le) (rate(order_service_http_request_duration_seconds_bucket[5m])))SQLPatternParser::get_groupbys(asap-common/dependencies/rs/sql_utilities/src/ast_matching/sqlpattern_parser.rs) returnsNonewhen the GROUP BY list is empty.Reproduce
cargo test -p query_engine_rust --test sql_compliance -- --nocapture; see the*_no_group_bycases inbasic.yamland the global aggregates in the other suites.