Re: pg_dump versus ancient server versions

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.

In response to

Responses

Browse pgsql-hackers by date

  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