From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Andres Freund <andres@anarazel.de>,
        Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
In-reply-to: <6f92dea3-9619-be68-239f-8990a832b453@dunslane.net>
References: 
 <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
 <202110222351.3f42l5fgo3lw@alvherre.pgsql>
 <CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
 <3783090.1635111977@sss.pgh.pa.us>
 <CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
 <3883429.1635171820@sss.pgh.pa.us>
 <20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
 <c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
 <22018.1635202338@sss.pgh.pa.us>
 <d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
 <20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
 <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
 <2316211.1638556231@sss.pgh.pa.us>
 <CA+Tgmob0V3dJ57vKL1iouk1oLMFn-60eAUQ+ab6=1BDG7ZC8iw@mail.gmail.com>
 <2978297.1638751274@sss.pgh.pa.us> <3794414.1639072240@sss.pgh.pa.us>
 <6f92dea3-9619-be68-239f-8990a832b453@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sat, 11 Dec 2021 10:17:17 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <70193.1639290264.1@sss.pgh.pa.us>
Date: Sun, 12 Dec 2021 01:24:24 -0500
Message-ID: <70194.1639290264@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/70194.1639290264%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@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