From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Feng Tian <ftian(at)vitessedata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Decimal64 and Decimal128 |
Date: | 2017-06-19 16:18:04 |
Message-ID: | 1627.1497889084@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> 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:
> We should have a very compelling reason for increasing the number of
> such hassles -- and, for me, this feature would not clear that bar.
It would be interesting to get some handle on the performance differences
between decNumber and our existing NUMERIC implementation. I'm a little
skeptical that they'd be so enormous as to make this an interesting
project, but I could be wrong.
Obviously, the answer could be very different when considering a
mostly-hardware implementation. But until those are fairly readily
available, it's hard to believe very many people will be excited.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-19 16:20:21 | Re: [HACKERS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger |
Previous Message | Shubham Barai | 2017-06-19 16:11:48 | GSoC 2017 weekly progress reports (week 3) |