On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote:
> On Mon, May 18, 2020 at 6:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > There surely are use-cases for true rational arithmetic, but I'm
> > dubious that it belongs in core Postgres. I don't think that enough
> > of our users would want it to justify expending core-project maintenance
> > effort on it. So I'd be happier to see this as an out-of-core extension.
>
> As is often the case, I'm a little more positive about including this
> than Tom, but as is also often the case, I'm somewhat cautious, too.
> On the one hand, I think it would be cool to have and people would
> like it. But, On the other hand, I also think we'd only want it if
> we're convinced that it's a really good implementation and that
> there's not a competing design which is better, or even equally good.
I vote for keeping it out of core, mostly because writing rational numeric
code is so different from writing DBMS core code. (Many of our existing
types, like numeric and the geometric types, have the same problem. Let's not
invite more of that.) The optimal reviewer pools won't have much overlap, so
patches may sit awhile and/or settle for a cursory review.
More language standard libraries provide "numeric"-style big decimals[1] than
provide big rationals[2], suggesting we're in good company.
[1] https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software#Languages
[2] https://en.wikipedia.org/wiki/Rational_data_type#Language_support
