-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
bugfix: wrong field type returned for SUM #15192
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15192 +/- ##
==========================================
+ Coverage 67.28% 67.32% +0.03%
==========================================
Files 1560 1560
Lines 192264 192417 +153
==========================================
+ Hits 129366 129543 +177
+ Misses 62898 62874 -24 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Andres Taylor <[email protected]>
Signed-off-by: Vicent Marti <[email protected]>
1fcafb1
to
a5d4474
Compare
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.
Looks like some legit unit test failures here too
|
||
scale := t.Scale() | ||
if code == AggregateAvg { | ||
scale += 4 |
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 think we also have to increase size
here too? I tested an AVG
and the size was also increased. Which makes sense, since size
for a decimal is the total number of digits, so if there's more digits behind the dot, it means the size also has to increase.
@@ -434,6 +438,7 @@ func (op *opArithMod) compile(c *compiler, left, right IR) (ctype, error) { | |||
c.asm.Mod_ff() | |||
case sqltypes.Decimal: | |||
ct.Type = sqltypes.Decimal | |||
ct.Scale = max(lt.Scale, rt.Scale) |
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 have to do the same with size here?
go/test/endtoend/utils/mysql.go
Outdated
t.Errorf("for column %s field types do not match\nNot equal: \nMySQL: %v\nVitess: %v\n", columnName, myField.Type.String(), vtField.Type.String()) | ||
} | ||
|
||
// ensure that Decimal types are properly sized |
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 want to check size here too?
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.
no we don't
Signed-off-by: Vicent Marti <[email protected]>
Signed-off-by: Vicent Marti <[email protected]>
@dbussink I'm not fixing the Size fields in this PR because they don't appear to affect correctness and their fix is significantly more involved, particularly for Decimals. We'll have to sit down and look at this together when you're back, I fear that some of the Size fields may not be computable statically! 😵 |
Signed-off-by: Vicent Marti <[email protected]>
Signed-off-by: Vicent Marti <[email protected]>
It all looks great to me ✨ . Since I opened the PR, you'll have to approve it, @vmg |
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.
AHA, SEAL OF SELF-APPROVAL 👌
Signed-off-by: Andres Taylor <[email protected]> Signed-off-by: Vicent Marti <[email protected]> Co-authored-by: Vicent Marti <[email protected]>
…5206) Signed-off-by: Andres Taylor <[email protected]> Signed-off-by: Vicent Marti <[email protected]> Co-authored-by: vitess-bot[bot] <108069721+vitess-bot[bot]@users.noreply.github.com> Co-authored-by: Vicent Marti <[email protected]>
Description
For some arithmetic operations performed in the evalengine, we were not setting the resulting decimal length correctly.
The values were correct, but since the decimal length was set wrongly, some clients didn't read all the provided decimals and got the wrong results.
Related Issue(s)
Fixes #15200
Checklist
Deployment Notes