Re: POC: rational number type (fractions)

Greetings,

* Andrew Dunstan (andrew(dot)dunstan(at)2ndquadrant(dot)com) wrote:
> On 5/22/20 1:53 AM, Noah Misch wrote:
> > 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(at)sss(dot)pgh(dot)pa(dot)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
>
> I agree. Also the original rationale that people want to use it on RDS
> is pretty awful. We can't just add in every extension that some DBAAS
> provider doesn't support.

I disagree with this and instead lean more towards the side that Robert
and Jeff were taking in that this would be a useful extension and
something we should consider including in core. I disagree with Tom and
Noah, specifically because, if we add this capability then I see our
potential use-cases as increasing and therefore getting more individuals
interested in working with us- to potentially include new contributors
and possibly committers.

> I think we mark this as rejected.

The more we reject new things, the less appealing our community ends up
being. I don't mean that to be an argument that we should accept
everything, but a new capability that has relatively little impact on
the core code and is useful should be something we're leaning towards
accepting rather than rejecting out of hand because it's not explicitly
called out in the SQL standard or appeals to the masses.

I'll further say that this is where we end up potentially loosing
newcomers to writing their own code in python or other tools when, if we
had such support in core, they'd be able to accomplish what they want
more easily with PG.

Thanks,

Stephen