-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
[SPARK-34012][SQL][2.4] Keep behavior consistent when conf spark.sqllegacy.parser.havingWithoutGroupByAsWhere
is true with migration guide
#31050
Conversation
…ry partition value" This reverts commit 4de3028.
….legacy.parser.havingWithoutGroupByAsWhere` is true with migration guide
FYI @maropu |
Looks fine if the tests pass. |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #133701 has finished for PR 31050 at commit
|
retest this please |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #133720 has finished for PR 31050 at commit
|
…legacy.parser.havingWithoutGroupByAsWhere` is true with migration guide ### What changes were proposed in this pull request? In #22696 we support HAVING without GROUP BY means global aggregate But since we treat having as Filter before, in this way will cause a lot of analyze error, after #28294 we use `UnresolvedHaving` to instead `Filter` to solve such problem, but break origin logical about treat `SELECT 1 FROM range(10) HAVING true` as `SELECT 1 FROM range(10) WHERE true` . This PR fix this issue and add UT. NOTE: This backport comes from #31039 ### Why are the changes needed? Keep consistent behavior of migration guide. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? added UT Closes #31050 from AngersZhuuuu/SPARK-34012-2.4. Authored-by: angerszhu <angers.zhu@gmail.com> Signed-off-by: Takeshi Yamamuro <yamamuro@apache.org>
Thanks! Merged to branch-2.4. |
What changes were proposed in this pull request?
In #22696 we support HAVING without GROUP BY means global aggregate
But since we treat having as Filter before, in this way will cause a lot of analyze error, after #28294 we use
UnresolvedHaving
to insteadFilter
to solve such problem, but break origin logical about treatSELECT 1 FROM range(10) HAVING true
asSELECT 1 FROM range(10) WHERE true
.This PR fix this issue and add UT.
NOTE: This backport comes from #31039
Why are the changes needed?
Keep consistent behavior of migration guide.
Does this PR introduce any user-facing change?
No
How was this patch tested?
added UT