Re: Do away with a few backwards compatibility macros

Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>

From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-27T10:59:18Z
Lists: 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



Commits

  1. Retire a few backwards compatibility macros.

  2. Retire MemoryContextResetAndDeleteChildren() macro.

  3. Simplify code by getting rid of SPI_push, SPI_pop, SPI_restore_connection.

  4. tuplestore_donestoring() isn't needed anymore, but provide a no-op