On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro <thomas.mu...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
