Re: Official adoption of PGXN
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Josh Berkus <josh@berkus.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jim Nasby <Jim.Nasby@BlueTreble.com>, Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>, Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael.paquier@gmail.com>, Daniel Verite <daniel@manitou-mail.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, Vladimir Rusinov <vrusinov@google.com>, David Steele <david@pgmasters.net>, Cynthia Shang <cynthia.shang@crunchydata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "David E. Wheeler" <david@justatheory.com>
Date: 2017-02-14T20:39:26Z
Lists: 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, ...
Commits
-
Remove contrib/tsearch2.
- 7ada2d31f47f 10.0 landed
-
Create stub functions to support pg_upgrade of old contrib/tsearch2.
- eb43e851d6b3 9.6.0 cited
-
Add backwards-compatible declarations of some core GIN support functions.
- 6595dd04d136 9.1.0 cited
-
Fix bug with multiple evaluation of tsearch2 compatibility trigger, trigger
- 3ca7eddbb7c4 8.4.0 cited