On Fri, Sep 25, 2015 at 5:06 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2015-09-25 0:25 GMT+02:00 Jim Nasby <jim.na...@bluetreble.com>: >> >> On 9/24/15 3:35 PM, Peter Geoghegan wrote: >>> >>> I would worry about the implicit casts you've added. They might cause >>> problems. >> >> >> Given the cycle created between numeric->decimal and decimal->numeric, I >> can pretty much guarantee they will. In any case, I don't think implicit >> casting from numeric->decimal is a good idea since it can overflow. I'm not >> sure that the other direction is safe either... I can't remember offhand if >> casting correctly obeys typmod or not. >> >> BTW, have you talked to Pavel about making these changes to his code? >> Seems a shame to needlessly fork it. :/ > > > yes, he talked with me, and I gave a agreement to continue/enhance/fork this > project how will be necessary
Bumping this ancient thread to say that DECFLOAT appears to have landed in the SQL standard. I haven't looked at SQL:2016 myself by I just saw this on Markus Winand's Modern SQL blog: "There is a new type decfloat[(<precision>)] (T076)." http://modern-sql.com/blog/2017-06/whats-new-in-sql-2016 So far it's supported only by DB2 (inventor) and FirebirdSQL has just announced support in the next release. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers