ydb/yql/essentials/sql/v1/select_yql_aggregation.cpp, branch main

YQL-21048: Support Grouping function at YqlSelect

2026-04-28T16:57:44Z

Now `Grouping` function kindly works, but with some known bug, that will be fixed in the next PR. It gives 4 TPC-DS queries. commit_hash:e891401453cbd9d9d964f673053b856e55ea8b56

YQL-21046: Support window functions for YqlSelect

2026-04-28T11:53:09Z

This patch adds support for `RowNumber`, `CumeDist`, `NTile`, `Rank`, `DenseRank`, `PercentRank`, `Lead`, `Lag`, `FirstValue`, `LastValue` and `NthValue`. It gives +3 TPC-DS queries and +5 TPC-DS bugs unlocked. The callable `YqlWin` was introduces, having the following form: ```yqls (YqlWin 'function_name 'window_name '() # options (Void) # type slot ...) # args ``` During the callable type annotation and expansion the same code for implementation functions substitution is used and shared even with a pgSQL. There was an issue with a `listType` for `YqlAgg`, `YqlAggWin` and `YqlWin`, because it was built incorrectly by referencing an atom "row" instead of _that_ argument row. It is fixed with a new "type slot". Now it has 3 states: `(Void)`, which is set by translator just as a stub, `row` that is set by `YqlSetItemWrapper` during the `RebuildLambdaColumns`, so then on the `YqlWin` type annotation it can take this `row` and wrap it to the `listType`, pass to the function and call for a repetition, so in a next stage the `resultType` will be ready. commit_hash:256fc2cb359714a646a308359b340b1715919f5d

YQL-21046: Support window aggregation over YqlSelect

2026-04-20T08:22:28Z

Introduce `YqlAggWin` callable and adapt `PgWindow` as `YqlWindow`. The `YqlAggWin` is similar to `YqlAgg`, but with window reference (name) included. Moved `PgWindowWrapper` to `SqlWindowWrapper`. It gives +6 TPC-DS test cases. Window functions are not yet supported, because they have separate callables and an extra design is required. commit_hash:ccef4463fd994779da21514dc9f6f596c511bbfe

YQL-20436: Support Agg(DISTINCT x) for YqlSelect

2025-12-14T09:30:45Z

TODO commit_hash:c1d59638bbbf9ce20c8e1bcc08da82fecdb2fe17

YQL-20436: Translate GROUP BY to YqlSelect

2025-12-08T15:16:01Z

This patch adds a support for a basic aggregation on `YqlSelect` and includes translation, type annotation, expansion changes. There are `count`, `min`, `max`, `sum`, `avg` and other aggregations without parameters supported. `HAVING` support will be added in a future PRs. Support for (2+)-arg aggregation is postponed, as it is not required for TPCH queries. ### Translator The `std::expected` was passed though the function call hierarchy to gracefully do not support some aggregation functions. The translation unit `select_yql_aggregation` was introduced. It implements an alternative aggregation translation to `YqlAggFactory` and `YqlAgg` callables. It reuses an `extractor` body and `aggregation_traits_factory` from a legacy code, via dirty hack with a `friend` keyword, as I decided to make minimal changes on an existing code. For a query fragment: ```yql ... Sum(body) ... ``` Resulting YQLs AST looks like this: ```yqls (YqlAggApply (YqlAggFactory '"sum") '() # <-- Options (Void) # <-- Result type stub body') ``` ### Type Annotation I followed a plan described at the https://nda.ya.ru/t/psA5Gaji7PDe9R. Besides, new `PgXXX` to `YqlXXX` renames, there were introduced `YqlAggFactoryWrapper` and `YqlAggWrapper`. First just checks argument count and types, but the second does more sofisticated work. `YqlAggWrapper` acts in 2 stages. On the first stage it will write an expression with a `TypeOf` of a `Result` to a result type stub and then calls for a transformation pipeline repetition. On the second stage result type stub is typed and so it just defines its type to be equal to a type of the stub. The tricky thing here is to contruct this expression with `Result` type. To do this it needs to instantiate an aggregation traits factory with a correct `list_type` and an `extractor`. The `list_type` is just a `(ListType (TypeOf row))`, where `row` is an `Argument` from an enclosing `lambda` at `YqlResultItem`. An `extractor` is just a `(lambda (row) body')`. The traits are imported from the `mount/lib/aggregate.yqls`, then they are beta-reduced with constructed `list_type` and `extractor` expressions. Then the `state` method is extracted and beta-reduced with a `body`. Then the `finish` method is extracted and beta-reduced with a some `state`-expression. So the resulting expression is constructed. ### Expansion The `YqlAgg` is expanded at `BuildAggregationTraits` from `yql_co_pgselect`, that is nicely integrated into `PgSelect` expansion infrastructure. There it is sufficient just to import an aggregation traits factory and beta-reduce it with `list_type` and `extractor`, that are provided by the `PgSelect`-related code. ### Refactoring Loading an `ExprNode`s from a module, so I extracted a logic to `ImportReadonly` and `ImportDeeplyCopied` at `yql_module_helpers`. commit_hash:9303f00567dd423bedc334e7c7514584f5bd8cff