Re: POC: rational number type (fractions) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: POC: rational number type (fractions)
Date
Msg-id 75123976-d1ac-0170-0193-be41d3655cbf@2ndQuadrant.com
Whole thread Raw
In response to Re: POC: rational number type (fractions)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: POC: rational number type (fractions)
List pgsql-hackers
On 7/1/20 7:00 PM, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>>> 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.
>> FWIW, I'm entirely in favor of having this available as an extension.
>> But I'm not in favor of it being in core.  I'm afraid it will end up
>> like the geometric types, i.e. a backwater of not-very-good code that
>> gets little love because it's not in line with the core competencies
>> of a bunch of database geeks.  If it's a separate project, then we
>> could hope to attract interest from people who know the subject matter
>> better but would never dare touch the PG backend in general.  There's
>> also the whole project-management issue that we have finite resources
>> and so we can *not* afford to put every arguably-useful feature in core.
> The issue that you highlight regarding geometric types is really that we
> simply refuse to punt things from core, ever, and that's not a
> reasonable position to take for long-term sanity.  On the flip side,
> it's ridiculously rare for an extension to have any kind of real
> life as an independent project- yes, there's one big exception (PostGIS)
> because it's simply ridiculously useful, and a few other cases
> where one company/individual or another funds the work of a particular
> extension because they need it for whatever, but by and large,
> extensions outside of PG simply don't thrive as independent projects.
>
> There's various potential reasons for that, from being hard to find, to
> being hard to install and work with, to the fact that we don't have a
> centralized extension system (PGXN isn't really endorsed at all by
> core... and I don't really think it should be), and our general
> extension management system isn't particularly great anyway.
>


Then these are things we should fix. But the right fix isn't including
every extension in the core code.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Initial progress reporting for COPY command
Next
From: Daniel Gustafsson
Date:
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view