Re: pg_dump versus ancient server versions

On 02.12.21 18:30, Tom Lane wrote:
>> This assumes a yearly major release cadence.
>
> If the point is to not have to count dates carefully, why does the cadence
> matter?

If we were to change the release cadence, then it would be appropriate
to review this policy.

> I can get behind something roughly like this, but I wonder if it wouldn't
> be better to formulate the policy in a reactive way, i.e. when X happens
> we'll do Y. If we don't plan to proactively remove some code every year,
> then it seems like the policy really is more like "when something breaks,
> then we'll make an attempt to keep it working if the release is less than
> ten majors back; otherwise we'll declare that release no longer
> buildable."

This sounds like it would give license to accidentally break support for
old releases in the code and only fix them if someone complains. That's
not really what I would be aiming for.

> I agree with the idea of being conservative about what outside
> dependencies we will worry about for "buildable" old versions.
> (Your nearby message about Python breakage is a good example of
> why we must limit that.) But I wonder about, say, libxml or libicu,
> or even if we can afford to drop all the non-plpgsql PLs. An
> example of why that seems worrisome is that it's not clear we'd
> have any meaningful coverage of transforms in pg_dump with no PLs.
> I don't have any immediate proposal here, but it seems like an area
> that needs some thought and specific policy.

Yeah, I think questions like this will currently quickly lead to dead
ends. We are talking 5 years this, 10 years that here. Everybody else
(apart from RHEL) is talking at best in the range 3-5 years. We will
have to figure this out as we go.