-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-24916][SQL] Fix type coercion for IN expression with subquery #21871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…nf).orElse(findTightestCommonType(l.dataType, r.dataType))
…e(findWiderTypeForTwo(l.dataType, r.dataType))
…e(findWiderTypeWithoutStringPromotionForTwo(l.dataType, r.dataType))
…e(findTightestCommonType(l.dataType, r.dataType)).orElse(findWiderTypeForDecimal(l.dataType, r.dataType))
|
I think this is basically the same of what I proposed in #19635. Unfortunately, that PR got a bit stuck... |
| SELECT cast('2017-12-12 09:30:00' as date) in (cast('2017-12-12 09:30:00' as date), cast('2017-12-11 09:30:00.0' as timestamp)) FROM t; | ||
| SELECT cast('2017-12-12 09:30:00' as date) in (cast('2017-12-12 09:30:00' as date), cast('2017-12-11 09:30:00' as date)) FROM t; | ||
|
|
||
| SELECT * FROM t WHERE (cast(1 as tinyint)) IN (SELECT cast(1 as tinyint) FROM t); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to test all the combinations? We need most of such logics should be tested in findWiderTypeWithoutStringPromotionForTwo and we could have just few end to end tests.
|
Oh. It turns out that @dilipbiswal is talking about that PR. I didn't find it in your recent PR. Let’s wait if the test can pass. |
|
Test build #93538 has finished for PR 21871 at commit
|
|
workaround: SELECT * FROM t4
WHERE
(t4a, t4b, t4c) IN (SELECT t5a, t5b, t5c FROM t5);
->
SELECT * FROM t4
WHERE
(t4a, t4b, t4c) IN (SELECT CAST(t5a as DOUBLE), CAST(t5b AS STRING), CAST(t5c AS STRING) FROM t5); |
What changes were proposed in this pull request?
The below SQL will throw
AnalysisException. but it can success on Spark 2.1.x. This pr fix this issue.I tested the different combinations of getting
commonTypes, it looks likefindCommonTypeForBinaryComparison + findWiderTypeWithoutStringPromotionForTwois the best way.doublewithdecimalstringwithdoublestringwithintThe details can be found in the commit log.
How was this patch tested?
unit tests