From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
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>, 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-04 13:29:45 |
Message-ID: | 64a5214d-6cf1-cfa1-e2d8-c66c9777d4c8@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-07-03 18:18, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> On 7/2/20 10:01 AM, Tom Lane wrote:
>>> 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.
>
> Yeah. Can we analyze why it hasn't done better? Can we improve it
> rather than starting something completely new?
This should probably all be in a different thread. But yeah, I think a
bit more analysis of the problem is needed before jumping into action.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2020-07-04 13:53:28 | Re: pg_read_file() with virtual files returns empty string |
Previous Message | Ajin Cherian | 2020-07-04 13:13:01 | Re: Resetting spilled txn statistics in pg_stat_replication |