Re: [HACKERS] Official adoption of PGXN - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Official adoption of PGXN
Date
Msg-id 20170214203926.2zafjdzcaiosb4zz@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Official adoption of PGXN  (Josh Berkus <josh@berkus.org>)
Responses Re: [HACKERS] Official adoption of PGXN  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 2017-02-14 12:19:56 -0800, Josh Berkus wrote:
> On 02/14/2017 12:05 PM, Tom Lane wrote:
> > Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> >> First, just to clarify: my reasons for proposing "core adoption" of PGXN 
> >> are not technical in nature.
> > 
> > What do you think "core adoption" means?  Surely not that anything
> > associated with PGXN would be in the core distro.
> 
> One part of this would need to be having a designated committee of the
> Postgres community pick a set of "blessed" extensions for packagers to
> package.  Right now, contrib serves that purpose (badly).  One of the
> reasons we haven't dealt with the extension distribution problem is that
> nobody wanted to take on the issue of picking a list of blessed extensions.

I don't see the trust problem being solved by them being blessed unless
they're part of the regularly scheduled postgres back-branch
releases. Which essentially requires them to be in core, or increase the
release maintenance/management cost further.

We sure could have levels between "random github repo" and "in core
extension", but I don't see "bless external extensions" supplanting all
contrib stuff.  There's a few extension in contrib/ where that level
would make sense, and surely more outside, but I think moving all of
contrib to something externally managed would be horrible idea.


> You have to admit that it seems really strange in the eyes of a new user
> that ISN is packaged with PostgreSQL, whereas better-written and more
> popular extensions (like plv8, pg_partman or pgq) are not.

These actually seem like easy cases. plv8 has a massive external
dependency, pg_partman is a) relatively new, b) there's in-core
development of extensions, and pgq isn't exactly trivial, partially
written in python, ...



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] possibility to specify template database for pg_regress
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Small improvement to parallel query docs