-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
numbers: Swap NUMERIC and DECIMAL (#187)
I made a mistake, confusing the names of NUMERIC vs DECIMAL. NUMERIC is actually the exact type and DECIMAL is the more relaxed type, rather than the other way around. For prosperity, the *only* difference between these two types in the SQL standard is: ISO/IEC 9075-2:2016(E), 6.1, <data type>, Syntax Rules: > 26) NUMERIC specifies the data type exact numeric, with the decimal > precision and scale specified by the <precision> and <scale>. > > 27) DECIMAL specifies the data type exact numeric, with the decimal > scale specified by the <scale> and the implementation-defined decimal > precision equal to or greater than the value of the specified > <precision>. I have seen this interpreted as: DECIMAL can use more precision (than specified) if it's more storage efficient or otherwise favorable for the engine to do so. This is the reasoning behind vsql's DECIMAL implementation of storing the raw fraction instead of scaling the number to the exact NUMERIC value. This also fixes: 1. All exact numeric types (DECIMAL, NUMERIC, SMALLINT, INTEGER and BIGINT) were being converted to approximate types for comparison (=, >, etc). They are now compared as exact values. 2. Nowhere does it say say in the standard that exact values should be zero padded to the precision (ie. 1.200 for NUMERIC(4, 3)). In fact, it actually specifies that when converting an exact type to a variable-length character string it should not do that: ISO/IEC 9075-2:2016(E), 6.13, <cast specification>, General Rules: > 12) a) i) Let YP be the shortest character string that conforms to the > definition of <exact numeric literal> in Subclause 5.3, "<literal>", > whose scale is the same as the scale of SD and whose interpreted value > is the absolute value of SV. It could be argued that the string/display values do not need to follow this same specification as the situation is different. However, I think it's going to be less confusing long term if we treat these conversions the same everywhere. 3. Fixed a bug where casting a DECIMAL to DECIMAL of a higher precision would not result in more actual precision as expected.
- Loading branch information
1 parent
9895e3b
commit 061e53a
Showing
11 changed files
with
164 additions
and
102 deletions.
There are no files selected for viewing
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
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
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
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
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
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
Oops, something went wrong.