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

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.

The argument that we simply aren't able to ever extend the surface area
of the database server beyond simple types because anything else
requires specialized knowledge that general database hackers don't have
implies that every committee/maintainers must be a general database
hacker that knows all kinds of stuff about the innards of the kernel,
but that isn't the case, even among our committers today- different
folks have confidence working in different areas and that's an entirely
good thing that allows us to increase our pool of resources while not
expecting folks to be complete generalists.  How do we build on that,
while not ending up with code getting dumped on us and then left with us
to maintain?  That's the problem we need to solve, and perhaps other
projects can give us insight, but I certainly won't accept that we
simply must accept some glass ceiling regardless of how many people want
to help us move forward- let's find a sensible way for them to help us
move forward while not increasing drag to the point that we fall out of
the sky.

Thanks,

Stephen