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

Steve Carlin commented on CALCITE-7120:
---------------------------------------

I know I'm being repetitive here, but:  This is not logic in RexBuilder.   
Please see this link:
[https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/SqlNumericLiteral.java#L107-L111]

This is logic in SqlNumericLiteral, in the method:

 RelDataType createSqlType(RelDataTypeFactory typeFactory) 

In this method is the following logic:

 if ((l >= Integer.MIN_VALUE) && (l <= Integer.MAX_VALUE)) {

            result = SqlTypeName.INTEGER;         

} else {            

   result = SqlTypeName.BIGINT;          

}

Ask yourself what is this code doing.  It's deciding, based on the content of 
the data, NOT some general concept of what is a numeric, whether a variable is 
an INTEGER or a BIGINT.  Based on the range.  

That is EXACTLY the same thing I am doing.  The only difference is that it's 
slightly more granular.

This is called many times within the validator logic to produce a "correct" 
RelDataType.   This RelDataType is sometimes manipulated by type coercion.  I 
cannot turn off type coercion because it's a big hammer that solves many 
problems (e.g.I have an issue where my database explicitly allows 3 + null 
which fails without type coercion).

To say this should be solved at Logical RelNode time seems...well...wrong.  
RelNode logic, imo, is not meant to fix type issues.

 

> Allow SqlNumericLiteral to create more restrictive integer types
> ----------------------------------------------------------------
>
>                 Key: CALCITE-7120
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7120
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Steve Carlin
>            Priority: Major
>
> It would be nice if SqlNumericLiteral created more restrictive datatypes for 
> integers. 
> There is already some logic in there that differentiates between INTEGER and 
> BIGINT
>  
> {code:java}
>           if ((l >= Integer.MIN_VALUE) && (l <= Integer.MAX_VALUE)) {
>             result = SqlTypeName.INTEGER;
>           } else {
>             result = SqlTypeName.BIGINT;
>           }   
> {code}
> If we can enhance this for TINYINT and SMALLINT, oh how wonderful that would 
> be for me.
> Background: Without this, it is causing me to use various workarounds by 
> overriding methods that are less than ideal.  Upon upgrade from 1.37 to 1.40, 
> my current implementation failed.  A query such as ...
> "SELECT 1 INTERSECT SELECT tinyint_col FROM my_tbl" 
> ... is generating a validated SQLNode tree which casts the tinyint_col to an 
> INTEGER (when using type coercing) which causes me issues.  (side note, I 
> need type coercing enabled for other issues so I can't just turn it off)
> Should we do this via a config option?  Putting this in by default will 
> probably break a lot of people's code.
>  



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

Reply via email to