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
-
Retire a few backwards compatibility macros.
- 75680c3d805e 17.0 landed
-
Retire MemoryContextResetAndDeleteChildren() macro.
- 6a72c42fd5af 17.0 cited
-
Simplify code by getting rid of SPI_push, SPI_pop, SPI_restore_connection.
- 1833f1a1c3b0 10.0 cited
-
tuplestore_donestoring() isn't needed anymore, but provide a no-op
- dd04e958c8b0 7.4.1 cited