On Tue, Nov 14, 2017 at 6:49 PM, Kohei KaiGai <kai...@heterodb.com> wrote: > 2017-11-14 10:33 GMT+09:00 Thomas Munro <thomas.mu...@enterprisedb.com>: >> On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai <kai...@heterodb.com> wrote: >>> Any opinions? >> >> The only reason I can think of for having it in core is that you might >> want to use standard SQL notation FLOAT(10) to refer to it. Right now >> our parser converts that to float4 but it could map precisions up to >> 10 to float2. The need for such special treatment is one of my >> arguments for considering SQL:2016 DECFLOAT(n) in core PostgreSQL. >> But this case is different: FLOAT(10) already works, it just maps to a >> type with a larger significand, as permitted by the standard. So why >> not just do these short floats as an extension type? >> > Our extension will be able to provide its own "half" or "float2" data type > using CREATE TYPE, indeed. I thought it is useful to other people, even > if they are not interested in the in-database analytics with GPU, to reduce > amount of storage consumption. > > Of course, it is my opinion.
Perhaps what the world needs is a single extension called ieee754 that would provide binary16 AND decimal32, decimal64. Seems a bit unlikely to happen though, because even though that's a single standard the people who care about binary floats and the people who care about decimal floats go to different conferences and the other base isn't on their radar (joking, sort of). I also wonder if there could be some way to make it so that the FLOAT(n) and DECFLOAT(n) typename conversion happens somewhere outside the parser so that extensions can participate in that kind of trick... -- Thomas Munro http://www.enterprisedb.com
