Horton

Re: removing tsearch2

David E. Wheeler <david@justatheory.com>

View thread View on postgr.es
From: "David E. Wheeler" <david@justatheory.com>
To: Bruce Momjian <bruce@momjian.us>
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:00:20Z
Lists: pgsql-hackers 
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.

Best,

David

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