Re: POC: rational number type (fractions)

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Joe Nelson <joe(at)begriffs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: rational number type (fractions)
Date: 2020-07-03 15:43:30
Message-ID: aab6cb5c-654e-50d5-3a13-be465279f9eb@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/2/20 10:01 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> On 7/1/20 7:00 PM, Stephen Frost wrote:
>>> ... 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.
> Yeah. We *must not* simply give up on extensibility and decide that
> every interesting feature has to be in core. I don't have any great
> ideas about how we grow the wider Postgres development community and
> infrastructure, but that certainly isn't the path to doing so.
>
>

I've been thinking about this a bit. Right now there isn't anything
outside of core that seems to work well. PGXN was supposed to be our
CPAN equivalent, but it doesn't seem to have worked out that way, it
never really got the traction. I'm thinking about something different,
in effect a curated set of extensions, maintained separately from the
core. Probably the involvement of one or two committers would be good,
but the idea is that in general core developers wouldn't need to be
concerned about these. For want of a better name let's call it
postgresql-extras. I would undertake to provide buildfarm support, and
possibly we would provide packages to complement the PGDG yum and apt
repos. If people think that's a useful idea then those of us who are
prepared to put in some effort on this can take the discussion offline
and come back with a firmer proposal.

cheers

andrew

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-03 16:12:26 Re: Parallell hashjoin sometimes ignores temp_tablespaces
Previous Message Alvaro Herrera 2020-07-03 15:04:17 Re: Cache lookup errors with functions manipulation object addresses