From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Fri, 3 Dec 2021 17:19:47 +0100
Message-ID: <5dd7ec9c-0a46-6c77-1176-caca0c68c3c1@enterprisedb.com> (raw)
In-Reply-To: <2073703.1638466245@sss.pgh.pa.us>
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
<202110222351.3f42l5fgo3lw@alvherre.pgsql>
<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
<3783090.1635111977@sss.pgh.pa.us>
<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
<3883429.1635171820@sss.pgh.pa.us>
<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
<22018.1635202338@sss.pgh.pa.us>
<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
<2073703.1638466245@sss.pgh.pa.us>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@enterprisedb.com, tgl@sss.pgh.pa.us, andrew@dunslane.net, bruce@momjian.us, andres@anarazel.de, robertmhaas@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_dump versus ancient server versions
In-Reply-To: <5dd7ec9c-0a46-6c77-1176-caca0c68c3c1@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox