[
https://issues.apache.org/jira/browse/CALCITE-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866271#comment-17866271
]
xiong duan commented on CALCITE-6464:
-------------------------------------
I checked SQL-2003 and SQL-2016, here is the document:
{code:java}
If the declared type of both operands of a dyadic arithmetic operator is exact
numeric, then the declared
type of the result is an implementation-defined exact numeric type, with
precision and scale determined
as follows:
a) Let S1 and S2 be the scale of the first and second operands respectively.
b) The precision of the result of addition and subtraction is
implementation-defined, and the scale is the
maximum of S1 and S2.
c) The precision of the result of multiplication is implementation-defined, and
the scale is S1 + S2.
d) The precision and scale of the result of division are
implementation-defined.{code}
Now we know, Calcite is custom implementation.
> Type inference for DECIMAL division seems incorrect
> ---------------------------------------------------
>
> Key: CALCITE-6464
> URL: https://issues.apache.org/jira/browse/CALCITE-6464
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.37.0
> Reporter: Mihai Budiu
> Assignee: Tim Grein
> Priority: Minor
> Labels: pull-request-available
>
> This bug surfaces if one uses a custom type system, e.g., where DECIMAL is
> limited to (28, 10).
> The problem is in RelDataTypeSystem.deriveDecimalDivideType.
> The JavaDoc of this function gives the algorithm for deriving the division
> result type.
> According to these rules, if you divide two numbers of type DECIMAL(28, 10),
> you should get a result with type DECIMAL(28, 10).
> But the actual implementation infers a type of DECIMAL(28, 0), which seems
> incorrect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
