Steve Carlin created CALCITE-7132:
-------------------------------------
Summary: Inconsistency with type coercion and character types
Key: CALCITE-7132
URL: https://issues.apache.org/jira/browse/CALCITE-7132
Project: Calcite
Issue Type: Bug
Reporter: Steve Carlin
I'm filing this as a bug because I think someone should look at this.
Something doesn't seem right to me here. Behavior changed on my upgrade from
1.37 to 1.40, but there are multiple layers to this problem and I"m not sure of
the right thing to do.
In my code, I have a binary comparison between a VARCHAR(6) and a CHAR(6) (e.g
WHERE myvarchar_col = char_col). However, the type coercion is different when
I reverse the parameters, (e.g. WHERE char_col = myvarchar_col). The
inconsistency didn't exist in 1.37.
So The AbstractTypeCoercion.commonTypeForBinaryComparison method is
inconsistent in what it returns here. While there has been some new code
added, it has always been inconsistent, even in 1.37. It returns the 2nd type
with this line:
[https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/validate/implicit/AbstractTypeCoercion.java#L593]
(aside, in 1.37, it returned the first type, but I don't think that's relevant
to this since it's still inconsistent).
The AbstractTypeCoersion.needToCast() function also changed, and this is why I
now hit the problem. It used to skip casting before CALCITE-6350, but now it
will do the casting because of this line:
[https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql/validate/implicit/AbstractTypeCoercion.java#L290]
My guess would be that the fix for CALCITE-6350 is correct, but it exposed the
problem with the inconsistent return above?
cc: [~mbudiu]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
