[
https://issues.apache.org/jira/browse/CALCITE-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351335#comment-17351335
]
Julian Hyde commented on CALCITE-4615:
--------------------------------------
I really don't know how much "coercing" the rule should do. It's often better
to be passive - assert that things are the way they should be. But I don't know
in this case; I haven't had time to study the code.
My main point is that there should be tests for these cases and we should do
something sensible. The rule not firing is fine. Producing an invalid plan is
not.
> AggregateUnionTransposeRule may assign wrong aggregate function to input
> ------------------------------------------------------------------------
>
> Key: CALCITE-4615
> URL: https://issues.apache.org/jira/browse/CALCITE-4615
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.26.0
> Reporter: Vladimir Ozerov
> Priority: Major
>
> Consider the following query tree:
> {code}
> 1: Aggregate[SUM($0):BIGINT]
> 2: Union[$0:BIGINT]
> 3: Input[$0:BIGINT]
> 4: Input[$0:BIGINT NOT NULL]
> {code}
> The Union's row type is {{BIGINT}}, and Aggergate's row type is {{BIGINT}} as
> well.
> When the {{AggregateUnionTransposeRule}} rule pushes {{Aggregate}} below
> {{Union}}, it installs the aggregate call from the original {{Aggregate}} to
> new aggregates:
> {code}
> 1: Aggregate[SUM($0):BIGINT]
> 2: Union[$0:BIGINT]
> 3: Aggregate[SUM($0):BIGINT]
> 4: Input[$0:BIGINT]
> 5: Aggregate[SUM($0):BIGINT]
> 6: Input[$0:BIGINT NOT NULL]
> {code}
> This leads to a Litmus failure in the {{Aggregate}} on line 5 because the
> aggregate call returns {{BIGINT}}, while it should return {{BIGINT NOT NULL}}.
> The solution is to re-create aggregate calls for inputs and let Calcite
> deduce the return type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
