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

From Tom Lane
Subject Re: [HACKERS] Decimal64 and Decimal128
Date
Msg-id 27532.1497795857@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Decimal64 and Decimal128  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Decimal64 and Decimal128  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] outfuncs.c utility statement support
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] initdb initalization failure for collation "ja_JP"