Alvaro Herrera <alvhe...@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
