From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: pg_dump versus ancient server versions |
Date: | 2021-10-22 23:00:19 |
Message-ID: | CAKFQuwbqPto2ASa2vpXNWApanfzaAqBz1+wEyiW0G0gqyKjw0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 22, 2021 at 3:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Florin Irion | 2021-10-22 23:08:21 | Re: Reserve prefixes for loaded libraries proposal |
Previous Message | Michael Paquier | 2021-10-22 22:47:27 | Re: [PATCH] Fix memory corruption in pg_shdepend.c |