Re: Decimal64 and Decimal128

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:

I'm not sure it's a good idea to import code under another license,
but leaving that aside, are you volunteering to port every future
change made by the upstream project to our proposed in-tree copy, from
the day the patch is committed until forever? We've had a few
previous run-ins with this sort of thing: the time zone files, the
regular expression engine, the snowball stuff. They're not
fantastically high-maintenance but Tom definitely spends some amount
of time on a fairly regular basis updating them and porting over
changes, and they cause hassles with pgindent and so forth as well.
We should have a very compelling reason for increasing the number of
such hassles -- and, for me, this feature would not clear that bar.

I think that if one or both of these libraries are commonly-packaged
things that are reasonably likely to be installable on newer operating
system images using yum/apt-get/port/emerge/whatever then it would be
fine to have a configure switch --with-decfloat or whatever, which
when used includes support for PostgreSQL data types that use the
library. If those libraries aren't sufficiently commonly-packaged
that this will be realistic option for people, then I vote against
depending on them. In that case, we could have our own, from-scratch,
clean-room implementation that does not depend on anybody else's code
under some other license, or we could wait and see if they become more
mainstream.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company