[
https://issues.apache.org/jira/browse/CALCITE-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17449290#comment-17449290
]
Julian Hyde commented on CALCITE-4888:
--------------------------------------
As always, I recommend describing problems in the way that they manifest to end
user. In this case, the does not directly affect people who are using SQL; the
problem occurs when people call {{RelBuilder.in}} with arguments that are
different types.
If the types of the {{RelBuilder.in}} arguments are not compatible (e.g.
{{INTEGER}} and {{{}BOOLEAN{}}}, or {{INTEGER}} and {{{}DATE{}}}) then
{{RelBuilder}} should throw. There should be a test for that.
If the types are similar but not the same (e.g. {{INTEGER}} and {{SMALLINT}} or
{{CHAR(5)}} and {{{}CHAR(7){}}}) what should be behavior be? Should
{{RelBuilder}} introduce casts to the least restrictive type? I think so. But
what are the implications if, after casting, the arguments are no longer
literals?
[~jingzhang], Note that Jira does not use backticks.
> Unify type inferring logical for Sarg RexLiteral
> ------------------------------------------------
>
> Key: CALCITE-4888
> URL: https://issues.apache.org/jira/browse/CALCITE-4888
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jing Zhang
> Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-11-23-10-31-05-137.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There exists some inconsistency to infer type of Sarg RexLiteral.
> 1. The method `RexSargBuilder#getType` in `RexSimplify` using
> `rexBuilder.typeFactory.leastRestrictive(Util.distinctList(types));`
> 2. The methods `RexBuilder#makeIn` and `RexBuilder#makeBetween` using type of
> first ranges as Sarg RexLiteral's type.
> It's better to unify type inferring logical for Sarg RexLiteral.
> IMO, I think using
> `rexBuilder.typeFactory.leastRestrictive(Util.distinctList(types));` is more
> reasonable.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
