Re: PostgreSQL High Precision Support Extension. - Mailing list pgsql-hackers

On Tue, Sep 21, 2021 at 2:58 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Sep 21, 2021 at 1:30 PM A Z <poweruserm@live.com.au> wrote:
> > -A library like GMP, written in C, is an appropriate basis to start from and to include, for all OS platforms
involved.
>
> Are you aware of Daniele Varrazzo's extension
> https://github.com/dvarrazzo/pgmp/ ?  (Never looked into it myself,
> but this seems like the sort of thing you might be looking for?)

[A Z replied off-list and mentioned areas where pgmp falls short, but
I'll reply on-list to try to increase the chance of useful discussion
here...]

It seems to me that there are 3 or 4 different topics here:

1.  Can you find the functions GMP lacks in some other library?  For
example, if I understand correctly, the library "mpfr" provides a
bunch of transcendental functions for libgmp's types.  Are there other
libraries?  Can you share what you already know about the landscape of
relevant libraries and what's good or lacking from your perspective?
Or are you proposing writing entirely new numeric code (in which case
that's getting pretty far away from the topics we're likely to discuss
here...).

2.  Supposing there are suitable libraries that build on top of GMP,
would it be reasonable to make a separate extension that extends pgmp?
 That is, users install the pgmp extension to get the basic types and
functions, and then install a second, new extension "pmpfr" (or
whatever) to get access to more functions?

3.  You mentioned wanting portability and packages for platforms X, Y,
Z.  Packaging is something to worry about later, and not typically
something that the author of an extension has to do personally.  Once
you produce a good extension, it seems very likely that you could
convince the various package maintainers to pick it up (as they've
done for pgmp and many other extensions).  The only question to worry
about initially is how portable the libraries you depend on are.  For
what it's worth, I'd personally start by setting up a CI system for a
bunch of relevant OSes with all the relevant libraries installed, for
exploration; I could provide some pointers on how to do that if you
think that would be interesting.

4.  You talked about whether such types could be in PostgreSQL "core".
In my humble opinion (1) this is a textbook example of something that
belongs in an extension, and (2) things built on GNU/GPL libraries are
complicated and probably couldn't ever be included in core in our
BSD-licensed project anyway.  (In contrast, the SQL:2016 DECFLOAT(n)
types really should be included in the core system, because they're in
the SQL standard and we are a SQL implementation, and AFAIK the only
real thing stopping us from doing that is deciding which library to
use to do it, which is complicated.)