-
Notifications
You must be signed in to change notification settings - Fork 29.1k
[SPARK-40903][SQL][FOLLOWUP] Cast canonicalized Add as its original data type if necessary #38513
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -481,12 +481,12 @@ case class Add( | |
| // TODO: do not reorder consecutive `Add`s with different `evalMode` | ||
| val reorderResult = | ||
| orderCommutative({ case Add(l, r, _) => Seq(l, r) }).reduce(Add(_, _, evalMode)) | ||
| if (resolved && reorderResult.resolved && reorderResult.dataType == dataType) { | ||
| reorderResult | ||
| if (resolved && reorderResult.resolved && reorderResult.dataType != dataType) { | ||
| // SPARK-40903: Append cast for the canonicalization of decimal Add if the result data type is | ||
| // changed. Otherwise, it may cause data checking error within ComplexTypeMergingExpression. | ||
| Cast(reorderResult, dataType) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems to be the same idea that has come up previously: #38379 (comment) but my concerns (#38379 (comment)) were wrong, so LGTM.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the cast is better after seconds thought. |
||
| } else { | ||
| // SPARK-40903: Avoid reordering decimal Add for canonicalization if the result data type is | ||
| // changed, which may cause data checking error within ComplexTypeMergingExpression. | ||
| withCanonicalizedChildren | ||
| reorderResult | ||
| } | ||
| } | ||
| } | ||
|
|
||
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.
for safe, can we do this for decimal type only ? e.g
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.
@ulysses-you the current code seems fine. If there is a new data type in the future, we can still avoid the issue.
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.
I'm not worry about new data types, just want to avoid unnecessary logic for some unrelated data types like integer, float ..