Re: pg_dump versus ancient server versions

Hi,

On 2021-10-25 13:09:43 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > 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.

I think that'd be less of a concern if we had a documented policy
somewhere. It'd not be hard to include a version table in that policy to make
it easier to understand. We could even add it to the table in
https://www.postgresql.org/support/versioning/ or something similar.

> 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?

I think that's more confusing than helpful, because the support timeframes
then differ between releases. It's easier to just subtract a number of major
releases for from a specific major version. Especially if there's a table
somewhere.

> 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.

Yes, I think that'd be quite a bit too restrictive.

Greetings,

Andres Freund