| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |
| Date: | 2023-11-14 17:01:15 |
| Message-ID: | 20231114170115.GB2062604@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 14, 2023 at 04:36:44PM +0000, Dagfinn Ilmari Mannsåker wrote:
> 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.
I'm not aware of anything like that.
> 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.
It might be worth introducing pg_attribute_deprecated() in c.h. I'm not
too worried about this particular macro, but it seems handy in general.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-11-14 17:04:51 | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |
| Previous Message | Alvaro Herrera | 2023-11-14 16:49:59 | Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC |