Re: Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 2:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro
>> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>>> On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> What would be the point of that?
>
>>> We'd accept and display the new SQL:2016 standard type name with
>>> length, but by mapping it onto different internal types we could use a
>>> pass-by-value type when it fits in a Datum.
>
>> Uggh. I'll repeat what has been said on this mailing list many times
>> before: the SQL standards committee often seems to make life
>> unnecessarily difficult with its choice of syntax.
>
> We could do what we did with FLOAT(n), which is to accept the new
> typename syntax but convert it to simple typenames decfloatN, and
> not worry about reversing the transformation on output.
>
> But the real question is whether we want to get that deeply invested
> in a type that couldn't be considered standard for many years to come.
> (Unless somebody wants to write an all-software fallback implementation,
> which I sure don't.)

There are already two well known all-software implementations:

1. IBM's decNumber[1] seems to be the more popular and is about
20kloc with a choice of ICU or GPL license. pgdecimal[3] (the
experimental extension by Feng Tian and Pavel Stehule that this thread
announced) uses that (an earlier version used the C language extension
types like _Decimal64 instead). Several projects seem to be using it
in-tree, including GCC.
2. Intel's RDFPMathLib[2] is much larger.

So I guess the questions would be:

1. Intel or IBM?
2. In tree or out of tree dependency?
3. Also support the new C TS extension types (_Decimal64 etc) as an
alternative for C compilers that have the extension, for the benefit
of xlc/POWER systems?

I speculate that decNumber in-tree would be the path of least
resistance (assuming the "ICU 1.8.1 and later" license[4] would be
acceptable -- to my untrained eye it looks rather BSD-ish -- and
20kloc isn't viewed as excessive), and further that a standard
compliant version might have some good reasons to be in core rather
than in an extension like pgdecimal:

1. We'd need gram.y + format_type.c support to get the property I
mentioned above (standard typename mapping to more than one internal
type in order to get pass-by-value for good performance with the
Datum-sized variant).
2. There are probably some casts and conversions among this and the
existing number types and rules for parsing constants etc that finish
up needing core changes.

[1] http://speleotrove.com/decimal/
[2] https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library
[3] https://github.com/vitesse-ftian/pgdecimal
[4] https://spdx.org/licenses/ICU.html

--
Thomas Munro
http://www.enterprisedb.com