On Fri, Feb 10, 2017 at 12:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers