[
https://issues.apache.org/jira/browse/CALCITE-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011629#comment-18011629
]
Steve Carlin commented on CALCITE-7120:
---------------------------------------
To get even more specific about my headaches as to what I was alluding to above.
In 1.37, the query
"select 1 intersect select tinyint_col from mytbl"
produced the following RelNode tree:
LogicalIntersect(all=[false]), id = 7
LogicalValues(tuples=[[\{ 1 }]]), id = 1
LogicalProject(TINYINT_COL=[$2]), id = 6
LogicalTableScan(table=[[mytbl]]), id = 3
I was easily able to change the RelDataType for "1" to tinyint in this case as
suggested. A workaround hack, but yes, it worked fine.
My upgrade to 1.40 broke this code. Now it produces code which I can't argue
with it because it is more correct, because this is the purpose of the
validator! To make sure types are right! Here is the new fixed 1.40 RelNode
tree for this query:
LogicalIntersect(all=[false]), id = 7
LogicalValues(tuples=[[\{ 1 }]]), id = 1
LogicalProject(TINYINT_COL=[CAST($2):INTEGER]), id = 6
LogicalTableScan(table=[[mytbl]]), id = 3
Note that the types under LogicalIntersect now match to be all INTEGER columns!
Which is a good thing for validation logic!
But this change absolutely destroys my workaround. Now I have to closely
examine the underlying RelNodes underneath LogicalIntersect and get their types
to match up. At Logical time. Again, this seems absolutely wrong to me.
> 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)
