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