Andrew Dunstan <and...@dunslane.net> writes:
> 9.2 is how far back crake goes in testing pg_ugrade from old versions,
> so that could well be a convenient stopping point. For older versions
> there is still the possibility of building on older toolchains and
> running on modern ones. Yes it's more cumbersome, but it does mean we
> can test an awful long way back.
Right. I think the point of the current discussion is to ensure that,
if we expect new patches for pg_dump or psql to work against version-N
servers, that it's not too unpleasant for patch submitters to build
and test against version N. There's a different discussion to be had
about what we do if we receive a bug report about compatibility with
some more-ancient-than-that version. But that is, I hope, a far less
common scenario; so it's okay if it requires extra effort, and/or use
of setups that not everyone has handy.
Anyway, it seems like there's some consensus that 9.2 is a good
stopping place for today. I'll push forward with
(1) back-patching as necessary to make 9.2 and up build cleanly
on the platforms I have handy;
(2) ripping out pg_dump's support for pre-9.2 servers;
(3) ripping out psql's support for pre-9.2 servers.
In a preliminary look, it did not seem that (3) would save very
much code, but it seems like we ought to do it if we're being
consistent.
A point we've not discussed is whether to drop any bits of libpq
that are only needed for such old servers. I feel a bit more
uncomfortable about that, mainly because I'm pretty sure that
only a few lines of code would be involved, and it seems to have
more of an air of burning-the-bridges finality about it than (say)
dropping psql/describe.c support. On the other hand, the point
about what's required to test future patches still applies.
regards, tom lane
