[ https://issues.apache.org/jira/browse/CALCITE-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852603#comment-16852603 ]
Lai Zhou commented on CALCITE-2992: ----------------------------------- May be we can make the CAST translation to include this conversion logic , making the solution more generic. But there will be a lot of work to make the validator to work out for implicit casting, I'll spend some time to involve related issues. > Enhance implicit conversions when generating hash join keys for an > equiCondition > -------------------------------------------------------------------------------- > > Key: CALCITE-2992 > URL: https://issues.apache.org/jira/browse/CALCITE-2992 > Project: Calcite > Issue Type: Improvement > Components: core > Affects Versions: 1.19.0 > Reporter: Lai Zhou > Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Considering follow sql join: > > {code:java} > select t1.*,t2.* from t1 join t2 on t1.intValue=t2.longValue > {code} > as known in java : > > {code:java} > Integer intValue = 2; > Long longValue = 2L; > new Object[]{intValue}.hashCode().equals > ( > new Object[]{longValue}.hashCode() > ) > = false; > {code} > We shoudn't use the orginal Object as a key in the HashMap, > I think it'd be better to convert hash join keys to string and compare string > values. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)