Re: [HACKERS] removing tsearch2 - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] removing tsearch2
Date
Msg-id 33a26f58-745f-1753-ce5d-0f2c4a7e9720@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] removing tsearch2  (Josh Berkus <josh@berkus.org>)
Responses Re: [HACKERS] removing tsearch2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers

On 02/10/2017 01:27 PM, Josh Berkus wrote:
> On 02/10/2017 10:18 AM, Peter Geoghegan wrote:
>> On Fri, Feb 10, 2017 at 3:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> Works for me.
>>>> +1
>>> OK, that's three votes in favor of removing tsearch2 (from core,
>>> anyone who wants it can maintain a copy elsewhere).
>> +1.
>>
>> I'd also be in favor of either removing contrib/isn, or changing it so
>> that the ISBN country code prefix enforcement went away. That would
>> actually not imply and real loss of functionality from a practical
>> perspective, since you can still enforce that the check digit is
>> correct without any of that. I think that the existing design of some
>> parts of contrib/isn is just horrible.
> +1 to quick-fix it, -1 to just delete it.
>
> There's a bunch of these things in /contrib which really ought to be
> PGXN extensions (also CUBE, earthdistance, etc.).  However, one of the
> steps in that would be getting the mainstream platforms to package them
> so that users have a reasonable upgrade path, so I would not propose
> doing it for 10.
>



Part of the reason for keeping a number of extensions is that it helps
test our extension infrastructure. Also they server as good pieces of
example code. So I don't want to get rid of them all, or even any of
them that have any degree of significant use. I think these days
tsearch2 is very largely redundant, so that means there's a good reason
not to keep it. But that's not true of cube, isn etc.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal : For Auto-Prewarm.
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs