On Fri, Oct 7, 2016 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> pg_dump alleges support for dumping from servers back to 7.0. Would v10
> be a good time to remove some of that code? It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9). My initial thought is to cut support
> for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
> support for cases where the server lacks schemas or pg_depend, each of
> which requires a fair deal of klugery in pg_dump.
It's been a long time since I've seen any 7.x versions in the wild,
and the pg_dump stuff is a nuisance to maintain. +1 for dropping
support for anything pre-7.4. Anybody who is upgrading from 7.3 to 10
isn't likely to want to do it in one swing anyway. In the real world,
few upgrades span 14 major versions.
> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4). And maybe the server's support too,
> though that wouldn't save very much code. The argument for cutting this
> isn't so much that we would remove lots of code as that we're removing
> code that never gets tested, at least not by us.
>
> One small problem with cutting libpq's V2 support is that the server's
> report_fork_failure_to_client() function still sends a V2-style message.
> We could change that in HEAD, certainly, but we don't really want modern
> libpq unable to parse such a message from an older server. Possibly we
> could handle that specific case with a little special-purpose code and
> still be able to take out most of fe-protocol2.c.
I definitely think we can't remove client support for anything that
modern servers still send, even if we change 10devel so that it no
longer does so. I think we have to at least wait until all versions
that might send a message are EOL before removing client-side support
for it -- and maybe a bit longer than that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company