Horton

Re: Do away with a few backwards compatibility macros

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-21T15:52:03Z
Lists: pgsql-hackers 
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.

-- 
Nathan Bossart
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