Fix precision issues with filsize and duration literals #12872
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.
Description
As the title says, this PR fixes issues with fractional values in filesize and duration literal values. E.g.,
0.5wk
is now reported as3day 12hr
instead of3day
.Fixes #12858, fixes #10612, and fixes #9892.
Implementation wise, this splits the
Unit
type intoFilesizeUnit
andDurationType
. These types have a few helpful methods and are now used a few other places besides the parser. Additionally, this PR adds theExpr::Filesize
andExpr::Duration
cases to replace the existingExpr::ValueWithUnit
.User-Facing Changes
Breaking changes:
-.0GiB
used to not parse as a filesize even though-.0
is parsed as a valid float.i64
number of bytes or nanos now trigger a parser error.format filesize
now errors on an invalid filsize unit instead of silently continuing.Current (Known) Limitations
i64
even if the exponent is negative. E.g.,9223372036854775808e-1B
will give a parser error.10^abs(exponent)
must not be larger theni64::MAX
, otherwise an error is reported. The means that the only valid exponents are in the range[-18, +18]
.