[HACKERS] Official adoption of PGXN (was: removing tsearch2)

First, just to clarify: my reasons for proposing "core adoption" of PGXN 
are not technical in nature. My desire is to have an extension/add-on 
system that's officially endorsed and embraced by the official 
community, similar to CPAN, pypy, npm, etc. There's no technical reason 
we need PGXN to be a first class citizen, but IMHO making it a first 
class citizen would greatly enhance the usefulness of Postgres and 
strengthen & expand the community. That community expansion should 
eventually result in an increase in new contributors to the database 
code itself.

On 2/14/17 8:24 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Right; I think we need at least some amount of pgxn buildfarm coverage.
>> There probably also needs to be a way to officially bless certain
>> distributions. Unless there's a pretty significant need for an official
>> extension to be in contrib, it should go into PGXN.
>
> I'm not sure a need-based test is going to be entirely the right
> thing.  The advantage of having something in contrib is that the core
> developers will maintain it for you.

With fairly minimal effort, that could be true of something in another 
repository though.

> When things change from release
> to release, everything in contrib necessarily gets updated; things on
> PGXN or elsewhere only get updated if their owners update them.  There

Right, and the intricate tie between contrib and rest of the database is 
why I'm not proposing ditching contrib completely. There's clearly some 
cases when that close tie makes the contrib code significantly simpler. 
(Though, it'd certainly be great if we found a way to reduce the 
multi-version support overhead for all extension creators!)

> are several good things about that.  First, it means that people can
> rely on the stuff in contrib mostly sticking around for future
> releases, except occasionally when we decide to drop a module.
> Second, it gives maintainers of external modules examples of what they
> need to do to update their code when we change the core APIs.  Third,
> it's probably actually more efficient for one person to go sweep
> through a large number of modules and fix them all at once than if
> those things were all on PGXN with separate owners.  Now, you can
> overdo that: I don't want to be responsible for every module on PGXN
> or anything close to it.  But on balance I think there's a good case
> for shipping a substantial set of modules in contrib.

I agree with your points, but AFAIK there's no reason that needs to 
happen in contrib. There could certainly be a dedicated git.PG.org repo 
for official extensions. AFAICT that would meet all your points 
(understanding that code that really needed to be tied to specific 
versions could remain in contrib).

Another option would be to start with just publishing most/all of what's 
in contrib on PGXN. Most OS packaging solutions for contrib seem rather 
clunky/arbitrary to me, so having pgxnclient as an install option would 
probably be welcome to some users. This would mean an additional step in 
the release process, but AFAIK that could be hidden behind a single make 
target (whoever's doing the release would also need access to the 
relevant account on pgxn.org).

... points about current contrib modules that I agree with...

> There's a lot of good
> stuff in contrib, though, and I don't think we should be averse to
> adding more in the future.  It shouldn't be just that any random
> contrib module somebody writes can get dropped into the core
> distribution, but I think we ought to be open to reasonable proposals
> to add things there when it makes sense.

Right now contrib is serving two completely separate purposes:

1) location for code that (for technical reasons) should be tied to 
specific PG versions
2) indication of "official endorsement" of a module by the community

My view is that we've turned #2 into a nail simply because of the hammer 
we built for #1 (certainly understandable since contrib way pre-dates 
extensions, let alone PGXN).

The community has discussions (about once a year) about what should or 
shouldn't stay in contrib, and a lot of the decision making process ends 
up driven by #2. If we had another official distribution channel for 
extensions, we could completely separate #1 and #2: contrib is strictly 
for official community extensions that are greatly simplified by being 
in the main repo; all other official extensions live at <insert git URL 
here> / <list of URLs on PGXN.org>. With some effort (hopefully from 
newly attracted extension authors), #1 could probable be eliminated as 
well, to the benefit of other external projects.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)