Re: removing tsearch2

Magnus Hagander <magnus@hagander.net>

From: Magnus Hagander <magnus@hagander.net>
To: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Josh Berkus <josh@berkus.org>, Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, 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>
Date: 2017-02-13T08:37:57Z
Lists: pgsql-hackers
On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

> On 2/10/17 2:24 PM, Andrew Dunstan wrote:
>
>> There's a bunch of these things in /contrib which really ought to be
>>> PGXN extensions (also CUBE, earthdistance, etc.).  However, one of the
>>> steps in that would be getting the mainstream platforms to package them
>>> so that users have a reasonable upgrade path, so I would not propose
>>> doing it for 10.
>>>
>>
>> Part of the reason for keeping a number of extensions is that it helps
>> test our extension infrastructure. Also they server as good pieces of
>> example code. So I don't want to get rid of them all, or even any of
>> them that have any degree of significant use. I think these days
>> tsearch2 is very largely redundant, so that means there's a good reason
>> not to keep it. But that's not true of cube, isn etc.
>>
>
> That's based on an assumption that PGXN shouldn't be treated as part of
> the community effort, which I think is a mistake. Having a robust,
> community run extension/package/module framework has proven to be extremely
> valuable for other programming environments, and IMHO we should be striving
> to improve in that area.


Until pgxn has a way of helping users on for example Windows (or other
platforms where they don't have a pgxs system and a compiler around), it's
always going to be a "second class citizen".

It's certainly part of the community efforts in many ways, but it's a
significant loss of usability compared to things that are included. And
from the perspective of the testing the infrastructure, you'd loose a lot
of platform coverage (unless you can find a way to integrate pgxn building
with the buildfarm).

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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