On Fri, Oct 7, 2016 at 4:06 PM, Tom Lane <t...@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. >
+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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
