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.
+1 for doing it, and also picking a version that's "easily explainable". If we can say "now we support back to 8.0" that's a lot better than saying 8.1 or 7.4.
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.
Which is a pretty strong argument in itself.
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.
Thoughts?
I agree we want the new libpq to be able to deal with that one from old versions, because 9.6 isn't really old yet. We *should* probably change it in head for the future anyway, but that means we have to keep it around in libpq for quite a long while anyway.
Unless the special purpose code becomes long and complicated, I think that's the best way to do it.
