[
https://issues.apache.org/jira/browse/CALCITE-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877886#comment-17877886
]
Karamsetty Vishnu vardhan commented on CALCITE-6556:
----------------------------------------------------
can i take this issue and fix it?
> Return Data Type of CASE Statement is Incorrect
> -----------------------------------------------
>
> Key: CALCITE-6556
> URL: https://issues.apache.org/jira/browse/CALCITE-6556
> Project: Calcite
> Issue Type: Bug
> Reporter: Karamsetty Vishnu vardhan
> Assignee: Karamsetty Vishnu vardhan
> Priority: Major
>
> I have encountered an issue where Trino is throwing a stale view error when
> it shouldn't. My environment involves a table and a view created in hive.
> Here are the DDL statements used:
> Table I have created:
> create table test.DECBIGINTCHECK ( ID DECIMAL(12,0), NAME varchar);
> View I have created:
> create view test.decview2 as select name,case when ID=1 then 123456789012
> else id end as newid from test.DECBIGINTCHECK;
>
>
> As i dig deeper i found that trino is using linkedin-coral library to
> calculate the data types of columns and this linkedin-coral is using apache
> calcite.
> There the return type of "{*}case when ID=1 then 1234567890123 else id
> end{*}" of statement is coming decimal(12,0) instead of decimal(19,0). This
> is happening because the return type is calculated as the superset of then
> and else clauses return type.
> Here one clause return type is *BIGINT* and other one is {*}DECIMAL(12,0){*}.
> Found the root cause is
>
> SqlTypeFactoryImpl.leastRestrictiveSqlType function is not considering the
> edge case of one type having precision and other not having precision. which
> is pushing my use-case to
> where the calcite returns the leastrestrictive based on the precision values
> (Here precision of BIGINT is -1)
>
> This can be fixed by adding another flow in the if-else clause where one of
> the types doesn't have precision.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
