Re: pg_dump versus ancient server versions

I was thinking a bit about formulating a policy for pg_dump backward
compatibility, based on the discussions in this thread.

Premises and preparatory thoughts:

- Users (and developers) want pg_dump to support server versions that
are much older than non-EOL versions.

- Less critically, much-longer backward compatibility has also
historically been provided for psql, so keeping those two the same
would make sense.

- The policy for other client-side tools (list at [0]) is less clear
and arguably less important. I suggest we focus on pg_dump and psql
first, and then we can decide for the rest whether they want to
match a longer window, a shorter window, or a different policy
altogether (e.g., ecpg).

- If we are going to maintain compatibility with very old server
versions, we need to make sure the older server versions can at
least still be built while an allegedly-compatible client tool is
under support.

[0]: https://www.postgresql.org/docs/devel/reference-client.html

Proposal:

* pg_dump and psql will maintain compatibility with servers at least
ten major releases back.

This assumes a yearly major release cadence.

I use the count of major releases here instead of some number of
years, as was previously discussed, for two reasons. First, it makes
computing the cutoff easier, because you are not bothered by whether
some old release was released a few weeks before or after the
equivalent date in the current year for the new release. Second,
there is no ambiguity about what happens during the lifetime of a
major release: If major release $NEW supports major release $OLD at
the time of $NEW's release, then that stays the same for the whole
life of $NEW; we don't start dropping support for $OLD in $NEW.5
because a year has passed.

I say "at least" because I wouldn't go around aggressively removing
support for old releases. If $NEW is supposed to support 9.5 but
there is code that says `if (version > 9.4)`, I would not s/9.4/9.5/
that unless that code is touched for other reasons.

Then ...

* We keep old major release branches buildable as long as a new major
release that has support for that old release is under support.

Buildable for this purpose means just enough that you can use it to
test pg_dump and psql. This probably includes being able to run make
installcheck and use pg_dump and psql against the regression database.
It does not require support for any additional build-time options that
are not required for this purpose (e.g., new OpenSSL releases).
Conversely, it should be buildable with default compiler options. For
example, if it fails to build and test cleanly unless you use -O0,
that should be fixed. Fixes in very-old branches should normally be
backpatches that have stabilized in under-support branches. Changes
that silence compiler warnings in newer compilers are by themselves
not considered a backpatch-worthy fix.

(In some cases, the support window of typical compilers should be
considered. If adding support for a very new compiler with new
aggressive optimizations turns out to be too invasive, then that
compiler might simply be declared not supported for that release. But
we should strive to support at least one compiler that still has some
upstream support.)

This keep-buildable effort is on an as-needed basis. There is no
requirement to keep the buildability current at all times, and there
is no requirement to keep all platforms working at all times.
Obviously, any changes made to improve buildability should not
knowingly adversely affect other platforms.

(The above could be reconsidered if buildfarm support is available,
but I don't consider that necessary and wouldn't want to wait for it.)

There is no obligation on anyone backpatching fixes to supported
branches to also backpatch them to keep-buildable branches. It is up
to those working on pg_dump/psql and requiring testing against old
versions to pick available fixes and apply them to keep-buildable
branches as needed.

Finally, none of this is meant to imply that there will be any
releases, packages, security support, production support, or community
support for keep-buildable branches. This is a Git-repo-only,
developer-focusing effort.

Example under this proposal:

PG 15 supports PG 9.2
PG 14 supports PG 9.1
PG 13 supports PG 9.0
PG 12 supports PG 8.4
PG 11 supports PG 8.3
PG 10 supports PG 8.2

In practice, the effort can focus on keeping the most recent cutoff
release buildable. So in the above example, we really only need to
keep PG >=9.2 buildable to support ongoing development. The chances
that some needs to touch code pertaining to older versions in
backbranches is lower, so those really would need to be dealt with
very rarely.

The parent message has proposed to remove support for PG <9.0 from
master. But I think that was chosen mainly because it was a round
number. I suggest we pick a cutoff based on years, as I had
described, and then proceed with that patch.