Re: POC: rational number type (fractions)

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

In response to

Browse pgsql-hackers by date

  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