Re: pg_dump versus ancient server versions

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: pg_dump versus ancient server versions
Дата
Msg-id CAKFQuwbqPto2ASa2vpXNWApanfzaAqBz1+wEyiW0G0gqyKjw0A@mail.gmail.com
обсуждение исходный текст
Ответ на pg_dump versus ancient server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump versus ancient server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH] Fix memory corruption in pg_shdepend.c
Следующее
От: Florin Irion
Дата:
Сообщение: Re: Reserve prefixes for loaded libraries proposal