Re: Re: Adding IEEE 754:2008 decimal floating point and hardware support for it

From: Thomas Munro <munro(at)ip9(dot)org>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Adding IEEE 754:2008 decimal floating point and hardware support for it
Date: 2013-06-20 07:46:41
Message-ID: CADLWmXXb6vX6g9kB68whGw23j=MvzNwfNtkBZWkDQ++EKNSoGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20 June 2013 08:05, Thomas Munro <munro(at)ip9(dot)org> wrote:

> On 20 June 2013 06:45, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
>> If the performance isn't interesting it may still be worth adding for
>>
> compliance reasons, but if we can only add IEEE-compliant decimal FP by
>> using non-SQL-standard type names I don't think that's super useful. If
>> there are significant performance/space gains to be had, we could
>> consider introducing DECIMAL32/64/128 types with the same names used by
>> DB2, so people could explicitly choose to use them where appropriate.
>
>
> +1 for using the DB2 names.
>

On reflection, I should offer more than +1. I think that the IBM name
DECFLOAT(16) is better than DECIMAL64 because:

1) The number of significant decimal digits is probably of greater
importance to a typical end user than the number of binary digits used to
store it.
2) Other SQL types are parameterised with this notation, such as
VARCHAR(6) and DECIMAL(6, 2).
3) IEEE 754 has rather different semantics to SQL DECIMAL, I'm thinking
mainly of the behaviour of special values, so using a name like DECFLOAT(n)
instead of DECIMAL64 would draw greater attention to that fact (ie it's not
just a fixed sized DECIMAL).

Also, IBM was here first, and I *guess* they will propose DECFLOAT for
standardisation (they are behind proposals to add support to many other
languages), though I have no information on that.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2013-06-20 07:57:33 Re: Implementing incremental backup
Previous Message Vik Fearing 2013-06-20 07:37:08 Re: LEFT JOIN LATERAL can remove rows from LHS