This repository has been archived by the owner on Feb 20, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 501
Port TPL behavior for float literals. Change print behavior for REAL. #1586
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The old behavior of to_string is to always print to 6 decimal places. Failure case: prints 0.333333333 as 0.333333. The fmt lib will print as many decimal places as are available, but will not be able to print trailing 0s. Failure case: prints 0.333000 as 0.333. If we want to print trailing 0s, we can use stringstream and std::fixed. Failure case: prints 0.333 as 0.333000. In general, there is no good solution here. If precision matters, revive the decimal PR.
lmwnshn
added
bug
Something isn't working (correctness). Mark issues with this.
in-progress
This PR is being actively worked on and not ready to be reviewed or merged. Mark PRs with this.
ready-for-ci
Indicate that this build should be run through CI.
labels
May 20, 2021
Note that some functions are not Postgres-compliant.
Major Decrease in PerformanceSTOP: this PR has a major negative performance impact
|
Codecov Report
@@ Coverage Diff @@
## master #1586 +/- ##
==========================================
+ Coverage 81.32% 81.73% +0.41%
==========================================
Files 706 739 +33
Lines 49981 52045 +2064
==========================================
+ Hits 40645 42541 +1896
- Misses 9336 9504 +168
Continue to review full report at Codecov.
|
lmwnshn
added
ready-for-review
This PR passes all checks and is ready to be reviewed. Mark PRs with this.
and removed
in-progress
This PR is being actively worked on and not ready to be reviewed or merged. Mark PRs with this.
labels
May 23, 2021
tpan496
approved these changes
May 23, 2021
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.
LGTM. Should we be worried about the performance guard?
Nah, that thing is super noisy. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bug
Something isn't working (correctness). Mark issues with this.
ready-for-ci
Indicate that this build should be run through CI.
ready-for-review
This PR passes all checks and is ready to be reviewed. Mark PRs with this.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Heading
Port TPL behavior for float literals. Change print behavior for REAL.
Description
@tpan496 found a bug where values outside of float range were treated as 0 or inf.
We were casting doubles down into floats in the
bytecode_generator
.Something we missed when porting TPL2 and making the "64-bit instead of 32-bit by default" change.
It's another one of those "fixed in TPL" things so I went and yoinked that code.
This also changes the default behavior of printing real values, e.g.,
SELECT 0.3333;
.In general, there is no good solution here. Given a REAL, we don't know if it was float or double initially. If precision matters, revive the decimal PR.
Going with B. for now.
I hope this does not blow up float SQL-based tests...