Re: Do away with a few backwards compatibility macros - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Do away with a few backwards compatibility macros
Date
Msg-id CALj2ACV4dRfCqpmY+kgYxDuqAAqV_5iqFdaWvnuuUn79JXLv4A@mail.gmail.com
Whole thread Raw
In response to Re: Do away with a few backwards compatibility macros  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Do away with a few backwards compatibility macros
List pgsql-hackers
On Tue, Nov 21, 2023 at 9:22 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Tue, Nov 21, 2023 at 12:05:36AM -0500, Tom Lane wrote:
> > No objection here, but should we try to establish some sort of project
> > policy around this sort of change (ie, removal of backwards-compatibility
> > support)?  "Once it no longer matters for any supported version" sounds
> > about right to me, but maybe somebody has an argument for thinking about
> > it differently.
>
> That seems reasonable to me.  I don't think we need to mandate that
> backwards-compatibility support be removed as soon as it is eligible, but
> it can be considered fair game at that point.

I think it's easy to miss/enforce a documented policy. IMV, moving
towards pg_attribute_deprecated as Alvaro Herrera said in the other
thread https://www.postgresql.org/message-id/202311141920.edtj56saukiv%40alvherre.pgsql
can help. Authors then can declare the variables and functions as
deprecated so that the code compilation with
-Wno-deprecated-declarations can help track all such deprecated code.

Having said that, I'm all +1 if the v1 patch proposed in this thread gets in.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: PATCH: Add REINDEX tag to event triggers
Next
From: Amit Kapila
Date:
Subject: Re: logical decoding and replication of sequences, take 2