Re: Decimal64 and Decimal128

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.)

regards, tom lane