From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: "David G. Johnston" <david.g.johnston@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
In-reply-to: <20211025165620.all2726jlr7i2pid@alap3.anarazel.de>
References: <2923349.1634942313@sss.pgh.pa.us>
 <CAKFQuwbqPto2ASa2vpXNWApanfzaAqBz1+wEyiW0G0gqyKjw0A@mail.gmail.com>
 <2979833.1634945425@sss.pgh.pa.us>
 <20211025165620.all2726jlr7i2pid@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 25 Oct 2021 09:56:20 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4049940.1635181783.1@sss.pgh.pa.us>
Date: Mon, 25 Oct 2021 13:09:43 -0400
Message-ID: <4049941.1635181783@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4049941.1635181783%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>> Yeah.  I checked into when it was that we dropped pre-8.0 support
>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>> So moving the bar forward by five releases isn't at all out of line.
>> 8.4 would be eight years past EOL by the time v15 comes out.

> I'd really like us to adopt a "default" policy on this. I think it's a waste
> to spend time every few years arguing what exact versions to drop. I'd much
> rather say that, unless there are concrete reasons to deviate from that, we
> provide pg_dump compatibility for 5+3 releases, pg_upgrade for 5+1, and psql
> for 5 releases or something like that.

I agree with considering something like that to be the minimum support
policy, but the actual changes need a bit more care.  For example, when
we last did this, the technical need was just to drop pre-7.4 versions,
but we chose to make the cutoff 8.0 on the grounds that that was more
understandable to users [1].  In the same way, I'm thinking of moving the
cutoff to 9.0 now, although 8.4 would be sufficient from a technical
standpoint.

OTOH, in the new world of one-part major versions, it's less clear that
there will be obvious division points for future cutoff changes.  Maybe
versions-divisible-by-five would work?  Or versions divisible by ten,
but experience so far suggests that we'll want to move the cutoff more
often than once every ten years.

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/2661.1475849167%40sss.pgh.pa.us