Re: removing tsearch2

Jim Nasby <jim.nasby@bluetreble.com>

From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Magnus Hagander <magnus@hagander.net>
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>, "David E. Wheeler" <david@justatheory.com>
Date: 2017-02-14T13:37:50Z
Lists: pgsql-hackers
On 2/13/17 2:37 AM, Magnus Hagander wrote:
>     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".

I view that as more of a failing of pgxs than pgxn. Granted, the most 
common (only?) pgxn client right now is written in python, but it's 
certainly possible to run that on windows with some effort (BigSQL does 
it), and I'm fairly certain it's not that hard to package a python 
script as a windows .exe.

> 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).

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.
-- 
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