Horton

Re: Official adoption of PGXN

Jim Nasby <jim.nasby@bluetreble.com>

View thread View on postgr.es
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Andres Freund <andres@anarazel.de>, Josh Berkus <josh@berkus.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-18T04:14:02Z
Lists: pgsql-hackers 
On 2/14/17 2:39 PM, Andres Freund wrote:
>> 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.

I don't see why we'd have to touch blessed PGXN extensions any time 
there's a back-branch release. We don't do that with what's in core 
today. If we did want to do that (say, so that the extension version 
always matched the PG version), it wouldn't be hard to automate.

Obviously if there's a bug in an extension we'd want to do something, 
but tying that to the release would be completely optional.
-- 
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)

Commits

  1. Remove contrib/tsearch2.

  2. Create stub functions to support pg_upgrade of old contrib/tsearch2.

  3. Add backwards-compatible declarations of some core GIN support functions.

  4. Fix bug with multiple evaluation of tsearch2 compatibility trigger, trigger