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.
