Re: removing tsearch2

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: "David E. Wheeler" <david@justatheory.com>
Cc: Magnus Hagander <magnus@hagander.net>, Andres Freund <andres@anarazel.de>, Josh Berkus <josh@berkus.org>, Cynthia Shang <cynthia.shang@crunchydata.com>, Michael Paquier <michael.paquier@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, David Steele <david@pgmasters.net>, Fujii Masao <masao.fujii@gmail.com>, Vladimir Rusinov <vrusinov@google.com>, Daniel Verite <daniel@manitou-mail.org>, Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>
Date: 2017-02-27T21:53:18Z
Lists: pgsql-hackers
On Mon, Feb 27, 2017 at 01:00:20PM -0800, David E. Wheeler wrote:
> On Feb 27, 2017, at 12:04 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 
> > Just stating the obvious, but one of the reasons CPAN works so well is
> > that most of the modules are written in Perl and hence don't need
> > per-platform compilation.
> 
> There are a *lot* of C-baded modules on CPAN; and my guess is that, more often than not, Perl modules depend on other C-based modules.
> 
> I daresay a lot of PostgreSQL extensions can be written in pure SQL or PL/pgSQL.

Oh, does CPAN distribute compiled modules or requires users to compile
them.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


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