From: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |
Date: | 2023-11-14 16:36:44 |
Message-ID: | 871qcsnvfn.fsf@wibble.ilmari.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-11-14 16:49:59 | Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC |
Previous Message | Nathan Bossart | 2023-11-14 16:33:39 | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |