[
https://issues.apache.org/jira/browse/CALCITE-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871501#comment-17871501
]
Mihai Budiu commented on CALCITE-6464:
--------------------------------------
I will submit an alternative PR based on the SQL server algorithm, which is
described here:
https://learn.microsoft.com/en-us/sql/t-sql/data-types/precision-scale-and-length-transact-sql
I am not sure it's the best algorithm, but at least it's documented.
Postgres is not a good reference since it supports arbitrary precision
DECIMALs, and thus it has probably very different rules.
> 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)
