Re: [HACKERS] Decimal64 and Decimal128 - Mailing list pgsql-hackers

On Mon, Jun 19, 2017 at 2:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>>> On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas <robertmhaas@gmail.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