[
https://issues.apache.org/jira/browse/CALCITE-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351265#comment-17351265
]
Vladimir Ozerov commented on CALCITE-4615:
------------------------------------------
[~julianhyde] Yes, this UNION ALL only. Regarding the SMALLINT/BIGINT - AFAIU
we need to check types from all inputs for the given column index, find the
least restrictive one, and then "coerce" all other inputs to this type. Does it
make sense?
> 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)
