Re: removing tsearch2

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-02-10T18:41:00Z
Lists: pgsql-hackers
On Fri, Feb 10, 2017 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> That's not a bad idea, but I think it's an independent issue.  If the
>> hacks are still needed for an external module, we shouldn't go out of
>> our way to remove them even if we nuke tsearch2 (but we don't need to
>> maintain them going forward unless we get a complaint).  If they hacks
>> aren't still needed, they could be removed whether or not we keep
>> tsearch2 in contrib.  Unless I'm confused?
>
> Technically, it's probably independent of whether we keep tsearch2 in
> contrib.  I think (but haven't researched it) that it's more a matter
> of whether we care to still support direct upgrades from pre-release-N
> versions of tsearch2, for some N.  Politically though, I think it'll
> be easier to make an aggressive decision in that regard if we are
> tossing tsearch2 out of contrib.

I agree that it's OK to desupport direct upgrades from ancient
releases to the very latest code at some point in time, and if
somebody thinks that's important work to reduce future maintenance or
just to tidy up, I'm not going to oppose it strenuously.  But I
wouldn't be in any rush either.

Anyway, it seems like the consensus here is unanimous.  Unless there
are a LARGE number of contrary votes in the meanwhile, I'll go make
this happen sometime next week.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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