Repository navigation
sql: aggregation without GROUP BY is rejected #817
Description
Problem
A SQL aggregation without a GROUP BY clause is rejected, even though it is a single-layer query with a valid time range. The planner fails with SQL parse error: Failed to parse SQL query: ....
SELECT SUM(value) FROM data
WHERE time BETWEEN DATEADD(s, -300, NOW()) AND NOW()Equivalent PromQL: sum(sum_over_time(data[5m]))
This affects every global aggregate: SUM, COUNT, MIN, MAX, QUANTILE, COUNT(DISTINCT col). The same queries with GROUP BY <label> are supported.
More examples:
| SQL | PromQL |
|---|---|
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) returns None when the GROUP BY list is empty.
Reproduce
cargo test -p query_engine_rust --test sql_compliance -- --nocapture; see the *_no_group_by cases in basic.yaml and the global aggregates in the other suites.
Activity
milindsrivastava1997 commentedon Oct 11, 2026
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:
GROUP BYas an empty grouping-label set at outer and innerSELECTlevels.SUM,COUNT(column),MIN,MAX,QUANTILE, andCOUNT(DISTINCT column)through planning and execution-context construction.AVG,COUNT(*), arithmetic or multi-aggregate projections, missing time ranges, ungrouped non-aggregate projections, and nested matching/execution.GROUP BY ()out of scope because the upstream dialect parser rejects it.