[
https://issues.apache.org/jira/browse/CALCITE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743810#comment-17743810
]
Runkang He commented on CALCITE-5838:
-------------------------------------
[~pfzhan] IMO this is a meaningful issue, since there is no strict
specification for decimal division's result type in ANSI standard:
The precision and scale of the result of division are implementation-defined.
Maybe we should list the prons and cons of default rule and your rule, if
default rule is more reasonable, and covers more scenes, we may define specific
rule, if not, could be better to change default rule.
> derive wrong decimal divide type
> --------------------------------
>
> Key: CALCITE-5838
> URL: https://issues.apache.org/jira/browse/CALCITE-5838
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.34.0
> Reporter: pengfei.zhan
> Priority: Major
> Fix For: 1.36.0
>
>
> Given a table metadata structure as follows:
> {code:sql}
> create table `tbl_test`(`CRR` decimal(38,2), `DT` varchar(4096)) ROW FORMAT
> DELIMITED FIELDS TERMINATED BY '\t';
> {code}
> If the following query is executed,
> {code:sql}
> select sum(CRR_0/1000000000.02) from (select sum(CRR) as CRR_0 from tbl_test
> where DT='20230705') T1
> {code}
> The RexCall CRR_0/1000000000.02 derived a decimal type of decimal(38, 0). I
> referred the derived type in spark, but it gives decimal(38, 4). It looks
> like the inferred type is more reasonable.
> [hive doc |
> https://cwiki.apache.org/confluence/download/attachments/27362075/Hive_Decimal_Precision_Scale_Support.pdf]
> [sql server doc | https://msdn.microsoft.com/en-us/library/ms190476.aspx]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
