On Fri, Feb 10, 2017 at 9:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> OK, that's three votes in favor of removing tsearch2 (from core,
>> anyone who wants it can maintain a copy elsewhere). Starting a new
>> thread to make sure we collect all the relevant votes, but I really,
>> really think it's past time for this to go away. The last actual
>> change to tsearch2 which wasn't part of a wider cleanup was
>> 3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
>> 7 years since there's been any real work done on this -- and the
>> release where we brought tsearch into core is now EOL, plus three more
>> releases besides.
>
> I'm abstaining on the actual vote, but I just wanted to note that there's
> at least two layers of stub compatibility functions in core that are
> there only to support tsearch2, cf commits
> eb43e851d6b3fa0c4516efcfdf29a183f7717a43
> 6595dd04d136d5c97ae05fc580572c8f00042143
> ... and there might be more that I missed in quickly scanning the
> commit log. We should probably investigate whether those can be
> gotten rid of without damaging the maintainability of the external
> module. I *think* these were only needed as short-term hacks but
> don't want to say for sure because ENOCAFFEINE.
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company