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(dot)Nasby(at)bluetreble(dot)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)