Re: pg_dump versus ancient server versions - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pg_dump versus ancient server versions
Date
Msg-id CAKFQuwbqPto2ASa2vpXNWApanfzaAqBz1+wEyiW0G0gqyKjw0A@mail.gmail.com
Whole thread Raw
In response to pg_dump versus ancient server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump versus ancient server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 22, 2021 at 3:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Anyway, I think the default answer is "revert 92316a458 and keep the
compatibility goalposts where they are".  But I wanted to open up a
discussion to see if anyone likes the other approach better.

[1] https://www.postgresql.org/message-id/20211022055939.z6fihsm7hdzbjttf%40alap3.anarazel.de


I'd rather drop legacy support than revert.  Even if the benefit of 92316a456 of is limited to refactoring the fact it was committed is enough for me to feel it is a worthwhile improvement.  It's still yet another five years before there won't be a supported release that can dump/restore this - so 20 years for someone to have upgraded without having to go to the (not that big a) hassle of installing an out-of-support version as a stop-over.

In short, IMO, the bar for this kind of situation should be 10 releases at most - 5 of which would be in support at the time the patch goes in.  We don't have to actively drop support of older stuff but anything older shouldn't be preventing new commits.

David J.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Fix memory corruption in pg_shdepend.c
Next
From: Florin Irion
Date:
Subject: Re: Reserve prefixes for loaded libraries proposal