[
https://issues.apache.org/jira/browse/CALCITE-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882084#comment-16882084
]
Praveen Kumar Desabandu commented on CALCITE-3187:
--------------------------------------------------
[~danny0405]
Yes we have our own StdOperatorTable but in a lot of internal optimization
we've noticed that Calcite is coded to prefer its internal operators[2]
Also product and quotient[1] for decimal is already being done in typeFactory
allowing clients to override the derivation if required. I am proposing to make
all decimal operations consistently derive return types from typeFactory.
[1][https://github.com/apache/calcite/blob/4d04773054c5bda3b43c3dbeb2be01df19cbe3e3/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeFactory.java#L298]
[2][https://github.com/apache/calcite/blob/8a2578787910e3c05c4d17006439de1940c0b195/core/src/main/java/org/apache/calcite/rel/rules/AggregateReduceFunctionsRule.java#L375]
This is most convenient and backward compatible method that i could think of.
> Derive all decimal return type through type factory
> ---------------------------------------------------
>
> Key: CALCITE-3187
> URL: https://issues.apache.org/jira/browse/CALCITE-3187
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Praveen Kumar Desabandu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently decimal product and quotient return types are derived through type
> factory, this allows clients to override the return type if they so desire.
> But decimal sum is embedded in return types, also decimal mod does not have a
> return type inference defined.
> This task is to derive all of the return types through type factory, so that
> clients can override if they wish to.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
