[
https://issues.apache.org/jira/browse/CALCITE-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darpan Lunagariya (e6data computing) updated CALCITE-7640:
----------------------------------------------------------
Description:
h2. Background
CALCITE-7631 introduced {{RexImplementorTable}} so custom operators defined
through a {{SqlOperatorTable}} can provide their own implementors. The scalar
enumerable path uses this table, but the aggregate path still looks up
implementors directly from the built-in {{RexImpTable}} singleton.
h2. Problem
The aggregate path consults the built-in singleton in two places:
* *Planning time*: the {{EnumerableAggregate}} constructor checks each
{{AggregateCall}} against {{RexImpTable.INSTANCE}} and throws
{{InvalidRelException}} if no implementor is found. {{EnumerableAggregateRule}}
catches this and returns {{null}}, so aggregates unknown to the built-ins are
rejected during planning.
* *Code-generation time*: {{AggImpState}} also resolves aggregate implementors
from {{RexImpTable.INSTANCE}}.
Because both paths hard-code the singleton, a chained {{RexImplementorTable}}
containing custom aggregate implementors is ignored.
Implementor availability is a planner-dependent decision. It depends on the
active implementor table, which is available through the planner context, not
through the {{EnumerableAggregate}} constructor alone.
h2. Desired Behavior
Aggregate implementor lookup should use the active {{RexImplementorTable}},
falling back to the built-in table when none is registered.
This would allow custom aggregate functions such as {{APPROX_TOP_K}} or
{{APPROX_COUNT_DISTINCT}}, whose implementation may vary from engine to engine,
to be implemented outside the built-in {{RexImpTable}} and still work with the
enumerable engine.
h2. Testing
End-to-end enumerable tests for a custom aggregate implementor, asserting the
actual result values.
The tests should cover:
* SQL execution through the {{Frameworks}} API.
* A directly built planner using a registered custom {{RexImplementorTable}}.
* A negative case where an unknown aggregate is rejected when no custom
implementor table is registered.
was:
h2. Background
CALCITE-7631 introduced {{RexImplementorTable}} so custom operators defined
through a {{SqlOperatorTable}} can provide their own implementors. The scalar
enumerable path uses this table, but the aggregate path still looks up
implementors directly from the built-in {{RexImpTable}} singleton.
h2. Problem
The aggregate path consults the built-in singleton in two places:
* *Planning time*: the {{EnumerableAggregate}} constructor checks each
{{AggregateCall}} against {{RexImpTable.INSTANCE}} and throws
{{InvalidRelException}} if no implementor is found. {{EnumerableAggregateRule}}
catches this and returns {{null}}, so aggregates unknown to the built-ins are
rejected during planning.
* *Code-generation time*: {{AggImpState}} also resolves aggregate implementors
from {{RexImpTable.INSTANCE}}.
Because both paths hard-code the singleton, a chained {{RexImplementorTable}}
containing custom aggregate implementors is ignored.
Implementor availability is a planner-dependent decision. It depends on the
active implementor table, which is available through the planner context, not
through the {{EnumerableAggregate}} constructor alone.
h2. Desired Behavior
Aggregate implementor lookup should use the active {{RexImplementorTable}},
falling back to the built-in table when none is registered.
This would allow custom aggregate functions such as {{APPROX_TOP_K}} or
{{APPROX_COUNT_DISTINCT}} to be implemented outside the built-in
{{RexImpTable}} and still work with the enumerable engine.
h2. Testing
End-to-end enumerable tests for a custom aggregate implementor, asserting the
actual result values.
The tests should cover:
* SQL execution through the {{Frameworks}} API.
* A directly built planner using a registered custom {{RexImplementorTable}}.
* A negative case where an unknown aggregate is rejected when no custom
implementor table is registered.
> Enumerable engine should execute aggregates whose implementor comes from a
> custom RexImplementorTable"
> ------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7640
> URL: https://issues.apache.org/jira/browse/CALCITE-7640
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.42.0
> Reporter: Darpan Lunagariya (e6data computing)
> Assignee: Darpan Lunagariya (e6data computing)
> Priority: Minor
> Labels: pull-request-available
>
> h2. Background
> CALCITE-7631 introduced {{RexImplementorTable}} so custom operators defined
> through a {{SqlOperatorTable}} can provide their own implementors. The scalar
> enumerable path uses this table, but the aggregate path still looks up
> implementors directly from the built-in {{RexImpTable}} singleton.
> h2. Problem
> The aggregate path consults the built-in singleton in two places:
> * *Planning time*: the {{EnumerableAggregate}} constructor checks each
> {{AggregateCall}} against {{RexImpTable.INSTANCE}} and throws
> {{InvalidRelException}} if no implementor is found.
> {{EnumerableAggregateRule}} catches this and returns {{null}}, so aggregates
> unknown to the built-ins are rejected during planning.
> * *Code-generation time*: {{AggImpState}} also resolves aggregate
> implementors from {{RexImpTable.INSTANCE}}.
> Because both paths hard-code the singleton, a chained {{RexImplementorTable}}
> containing custom aggregate implementors is ignored.
> Implementor availability is a planner-dependent decision. It depends on the
> active implementor table, which is available through the planner context, not
> through the {{EnumerableAggregate}} constructor alone.
> h2. Desired Behavior
> Aggregate implementor lookup should use the active {{RexImplementorTable}},
> falling back to the built-in table when none is registered.
> This would allow custom aggregate functions such as {{APPROX_TOP_K}} or
> {{APPROX_COUNT_DISTINCT}}, whose implementation may vary from engine to
> engine, to be implemented outside the built-in {{RexImpTable}} and still work
> with the enumerable engine.
> h2. Testing
> End-to-end enumerable tests for a custom aggregate implementor, asserting the
> actual result values.
> The tests should cover:
> * SQL execution through the {{Frameworks}} API.
> * A directly built planner using a registered custom {{RexImplementorTable}}.
> * A negative case where an unknown aggregate is rejected when no custom
> implementor table is registered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
