You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (Jira)" <ji...@apache.org> on 2023/06/23 14:59:00 UTC

[jira] [Commented] (CALCITE-5794) Constant folding of CAST(literal AS decimal_type) ignores scale parameter of a target type

    [ https://issues.apache.org/jira/browse/CALCITE-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736522#comment-17736522 ] 

Julian Hyde commented on CALCITE-5794:
--------------------------------------

I’m not sure the plan is wrong. We use java BigDecimal objects to store all numeric literals, even integers. The scale of the BigDecimal doesn’t match the RelDataType scale, but that shouldn’t make a difference. The code generator should use the RelDataType scale. 

> Constant folding of CAST(literal AS decimal_type) ignores scale parameter of a target type
> ------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-5794
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5794
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Maksim Zhuravkov
>            Priority: Major
>
> Consider the following expression `CAST(100.00 AS DECIMAL(4,1))` it should transform `100.00` to `100.0`. But constant folding optimization removes a cast and the whole expression is replaced with `100.00` literal which is not correct.
> *Reproducer*:
> {code:java}
> // SqlToRelConverterTest
>  @Test void testCastLiteralToDecimal() {
>     final String sql = "SELECT CAST(100.00 AS DECIMAL(4,1))";
>     sql(sql).ok();
>   }
> {code}
> Produces this plan:
> {code:java}
> LogicalValues(tuples=[[{ 100.00 }]])
> {code}
> *Expected behavior*: Cast is not removed/cast expression is replaced with correct literal.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)