darpan-e6 opened a new pull request, #5074: URL: https://github.com/apache/calcite/pull/5074
## Jira Link [CALCITE-7640](https://issues.apache.org/jira/browse/CALCITE-7640) ## Changes Proposed Follow-up to CALCITE-7631. That change made `RexImplementorTable` composable for scalar code generation and constant reduction, but the aggregate path still resolved implementors through the `RexImpTable` singleton — so a custom aggregate operator (contributed through a `SqlOperatorTable` rather than registered as a schema function) could not be planned or executed by the enumerable engine, even when a `RexImplementorTable` that knows it was in scope. The singleton was consulted in two places: `EnumerableAggregate`'s constructor pre-checked each `AggregateCall` against `RexImpTable.INSTANCE` (throwing `InvalidRelException`, so the aggregate was rejected during planning), and `AggImpState` generated code against the singleton. - **`RexImplementorTables.of(RelOptCluster)`** — new accessor returning the `RexImplementorTable` registered on the planner `Context`, or `RexImpTable.instance()` when none is registered (the single place the default is named). `RelOptCluster` is only used to reach the planner context; it is not modified. - **Feasibility check moved to the rule** — the implementor-availability check now lives in `EnumerableAggregateRule.convert` (which has the planner, hence the injected table); it declines when the active table has no implementor so the planner can try another convention. The `EnumerableAggregate` constructor keeps only the table-independent structural checks (`DISTINCT` / `WITHIN DISTINCT`). - **Code generation threaded** — `AggImpState` takes a `RexImplementorTable`, supplied by its callers (`EnumerableAggregate`, `EnumerableSortedAggregate`, `EnumerableWindow`, and the interpreter's `AggregateNode`) from `RexImplementorTables.of(getCluster())`. The former 3-argument constructor is retained (deprecated) and delegates to the built-in table. Both the planning gate and code generation read the same table, so acceptance by the rule implies code generation can succeed. Behaviour is unchanged when no table is registered. `EnumerableCustomAggregateTest` adds end-to-end coverage: a custom aggregate whose implementor is supplied through a chained `RexImplementorTable` is planned as an `EnumerableAggregate` and executed — driven both through the `Frameworks` API (real SQL) and a directly built planner — asserting the actual result values; plus the negative case that an unknown aggregate is rejected when no custom table is registered. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
