Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro
Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
From: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-11-14T16:36:44Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2023-Nov-13, Nathan Bossart wrote: > >> Shall we retire this backwards compatibility macro at this point? A search >> of https://codesearch.debian.net/ does reveal a few external uses, so we >> could alternatively leave it around and just update Postgres to stop using >> it, but I don't think it would be too burdensome for extension authors to >> fix if we removed it completely. > > Let's leave the macro around and just remove its uses in PGDG-owned > code. Having the macro around hurts nothing, and we can remove it in 15 > years or so. Is there a preprocessor symbol that is defined when building Postgres itself (and extensions in /contrib/), but not third-party extensions (or vice versa)? If so, the macro could be guarded by that, so that uses don't accientally sneak back in. There's also __attribute__((deprecated)) (and and __declspec(deprecated) for MSVC), but that can AFAIK only be attached to functions and variables, not macros, so it would have to be changed to a static inline function. - ilmari
Commits
-
Retire MemoryContextResetAndDeleteChildren() macro.
- 6a72c42fd5af 17.0 landed
-
Simplify code by getting rid of SPI_push, SPI_pop, SPI_restore_connection.
- 1833f1a1c3b0 10.0 cited
-
Redefine MemoryContextReset() as deleting, not resetting, child contexts.
- eaa5808e8ec4 9.5.0 cited
-
tuplestore_donestoring() isn't needed anymore, but provide a no-op
- dd04e958c8b0 7.4.1 cited