[
https://issues.apache.org/jira/browse/CALCITE-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702153#comment-17702153
]
Julian Hyde commented on CALCITE-5592:
--------------------------------------
The summary describes a fix rather than a problem. So, let's identify the
problem.
Does the validator treat the query as valid when it should be invalid? No, I
think the query should be valid.
But I don't remember whether the correct behavior is to implicitly cast a to
INTEGER or implicitly cast 1 to VARCHAR. Can you search jira or the code for
where we implemented that behavior?
If the type is inferred incorrectly, as you allege, there will be symptoms -
maybe an exception thrown, or incorrect query results. What are those symptoms?
> SqlValidatorImpl#validateWhereOrOn does not derive the the correct operand
> type for '='
> ---------------------------------------------------------------------------------------
>
> Key: CALCITE-5592
> URL: https://issues.apache.org/jira/browse/CALCITE-5592
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jianhui Dong
> Priority: Major
>
> org.apache.calcite.sql.fun.SqlStdOperatorTable#EQUALS use
> InferTypes.FIRST_KNOWN as its SqlOperandTypeInference, and it will derive the
> type incorrectly as follows:
> {code:java}
> CREATE TABLE source (
> a VARCHAR
> )
> SELECT * FROM source WHERE a = 1;{code}
> it will think that the type of operands `source.a` and `1` both be
> VARCHAR(65536), but exactly the type of `1` maybe INTEGER, and I want to know
> if should we throw an exception for this kind type check of where clause?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
