Re: [HACKERS] Decimal64 and Decimal128
út 13. 11. 2018 v 0:55 odesílatel Tom Lane napsal: > Andres Freund writes: > > On 2018-11-13 00:01:49 +0100, David Fetter wrote: > >> So if this got added to a lot of compilers, that might suffice. > > > No, unless those compiler versions will automatically be available in > > older distros. Which they won't. > > Yeah. I think putting this in core is a long way off. Maybe somebody > will write an extension instead. > It is exists already https://github.com/okbob/pgDecimal - it is just experimental Maybe this code can be more interesting due JIT support. Regards Pavel > regards, tom lane >
Re: [HACKERS] Decimal64 and Decimal128
Andres Freund writes: > On 2018-11-13 00:01:49 +0100, David Fetter wrote: >> So if this got added to a lot of compilers, that might suffice. > No, unless those compiler versions will automatically be available in > older distros. Which they won't. Yeah. I think putting this in core is a long way off. Maybe somebody will write an extension instead. regards, tom lane
Re: [HACKERS] Decimal64 and Decimal128
On 2018-11-13 00:01:49 +0100, David Fetter wrote: > On Mon, Nov 12, 2018 at 02:57:37PM -0800, Andres Freund wrote: > > Hi, > > > > On 2018-11-12 23:51:35 +0100, David Fetter wrote: > > > On Tue, Nov 13, 2018 at 11:01:33AM +1300, David Rowley wrote: > > > > On 13 November 2018 at 10:39, Thomas Munro > > > > wrote: > > > > > ... and it has just been voted into the next revision of the C > > > > > language: > > > > > > > > > > https://gustedt.wordpress.com/2018/11/12/c2x/ > > > > > > > > Nice. Maybe we can get DECFLOAT into core around PostgreSQL 32 or so > > > > :-) > > > > > > That's the same schedule we were on for C99, assuming linearity. If > > > instead we assume that the speed increases with, say, more developers, > > > it seems reasonable to imagine that we'd have optional C2X features in > > > PostgreSQL 14 or 15, assuming support for it in at least two common > > > compiler toolchains ;) > > > > I don't think developer time is particularly relevant here. C99 adoption > > wasn't limited by somebody doing the work to make it so, but the desire > > to support some old platforms. I'm personally perfectly fine with being > > more aggressive around that, but there are some other quarters that are > > more resistant to such ideas... But even if we're more aggressive, 15 > > seems quite unrealistic - there'll be a lot of platforms that won't have > > a bleeding edge version of $compiler. > > So if this got added to a lot of compilers, that might suffice. No, unless those compiler versions will automatically be available in older distros. Which they won't. > Does this have any coupling to the C++ integration, or is it pretty > much orthogonal? Seems largely orthogonal. Greetings, Andres Freund
Re: [HACKERS] Decimal64 and Decimal128
On Mon, Nov 12, 2018 at 02:57:37PM -0800, Andres Freund wrote: > Hi, > > On 2018-11-12 23:51:35 +0100, David Fetter wrote: > > On Tue, Nov 13, 2018 at 11:01:33AM +1300, David Rowley wrote: > > > On 13 November 2018 at 10:39, Thomas Munro > > > wrote: > > > > ... and it has just been voted into the next revision of the C language: > > > > > > > > https://gustedt.wordpress.com/2018/11/12/c2x/ > > > > > > Nice. Maybe we can get DECFLOAT into core around PostgreSQL 32 or so :-) > > > > That's the same schedule we were on for C99, assuming linearity. If > > instead we assume that the speed increases with, say, more developers, > > it seems reasonable to imagine that we'd have optional C2X features in > > PostgreSQL 14 or 15, assuming support for it in at least two common > > compiler toolchains ;) > > I don't think developer time is particularly relevant here. C99 adoption > wasn't limited by somebody doing the work to make it so, but the desire > to support some old platforms. I'm personally perfectly fine with being > more aggressive around that, but there are some other quarters that are > more resistant to such ideas... But even if we're more aggressive, 15 > seems quite unrealistic - there'll be a lot of platforms that won't have > a bleeding edge version of $compiler. So if this got added to a lot of compilers, that might suffice. Does this have any coupling to the C++ integration, or is it pretty much orthogonal? Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Re: [HACKERS] Decimal64 and Decimal128
Hi, On 2018-11-12 23:51:35 +0100, David Fetter wrote: > On Tue, Nov 13, 2018 at 11:01:33AM +1300, David Rowley wrote: > > On 13 November 2018 at 10:39, Thomas Munro > > wrote: > > > ... and it has just been voted into the next revision of the C language: > > > > > > https://gustedt.wordpress.com/2018/11/12/c2x/ > > > > Nice. Maybe we can get DECFLOAT into core around PostgreSQL 32 or so :-) > > That's the same schedule we were on for C99, assuming linearity. If > instead we assume that the speed increases with, say, more developers, > it seems reasonable to imagine that we'd have optional C2X features in > PostgreSQL 14 or 15, assuming support for it in at least two common > compiler toolchains ;) I don't think developer time is particularly relevant here. C99 adoption wasn't limited by somebody doing the work to make it so, but the desire to support some old platforms. I'm personally perfectly fine with being more aggressive around that, but there are some other quarters that are more resistant to such ideas... But even if we're more aggressive, 15 seems quite unrealistic - there'll be a lot of platforms that won't have a bleeding edge version of $compiler. Greetings, Andres Freund
Re: [HACKERS] Decimal64 and Decimal128
On Tue, Nov 13, 2018 at 11:01:33AM +1300, David Rowley wrote: > On 13 November 2018 at 10:39, Thomas Munro > wrote: > > ... and it has just been voted into the next revision of the C language: > > > > https://gustedt.wordpress.com/2018/11/12/c2x/ > > Nice. Maybe we can get DECFLOAT into core around PostgreSQL 32 or so :-) That's the same schedule we were on for C99, assuming linearity. If instead we assume that the speed increases with, say, more developers, it seems reasonable to imagine that we'd have optional C2X features in PostgreSQL 14 or 15, assuming support for it in at least two common compiler toolchains ;) Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Re: [HACKERS] Decimal64 and Decimal128
On 13 November 2018 at 10:39, Thomas Munro wrote: > ... and it has just been voted into the next revision of the C language: > > https://gustedt.wordpress.com/2018/11/12/c2x/ Nice. Maybe we can get DECFLOAT into core around PostgreSQL 32 or so :-) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] Decimal64 and Decimal128
On Fri, Jun 16, 2017 at 9:42 AM Thomas Munro wrote: > On Fri, Sep 25, 2015 at 5:06 PM, Pavel Stehule > wrote: > > 2015-09-25 0:25 GMT+02:00 Jim Nasby : > >> 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: ... and it has just been voted into the next revision of the C language: https://gustedt.wordpress.com/2018/11/12/c2x/ -- Thomas Munro http://www.enterprisedb.com
