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.na...@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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
