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
