Horton

Re: Official adoption of PGXN (was: removing tsearch2)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Nasby <Jim.Nasby@BlueTreble.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Josh Berkus <josh@berkus.org>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>, 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:05:55Z
Lists: pgsql-hackers 
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.

> 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

This argument ignores what I think is the real technical reason for
keeping contrib, which is to have a set of close-at-hand test cases
for extension and hook mechanisms.  Certainly, not every one of the
existing contrib modules is especially useful for that purpose, but
quite a few of them are.

			regards, tom lane

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