Hi,
On Fri, Oct 31, 2025 at 01:19:50PM +0100, Álvaro Herrera wrote:
> On 2025-Oct-31, Bertrand Drouvot wrote:
>
> > After giving it more thought, I'm inclined to postpone the compiler warning
> > until XLogRecPtrIsValid() has been available for some time. The question is for
> > how long?
>
> Maybe we can mark it so that it becomes obsolete in a future version,
>
> #if PG_VERSION_NUM >= 210000
> [[obsolete]]
> #endif
> XLogRecPtrIsInvalid( .. )
>
> so that people using it today won't get any noise, but once they do get
> the warning, the versions without the other macro are already out of
> support, so they can switch to the new one easily. (This presupposes
> that we'd add the new macro to older branches as well, which shouldn't
> be a problem.) Only extensions wishing to support PG versions older
> than we support would have to work slightly harder, but that should be OK.
Yeah, I did not think of checking PG_VERSION_NUM for a "future" version, that's
a good idea! I did it that way in the attached (in 0002) and introduced
PG_DEPRECATED() (as suggested by Peter upthread).
The version check is done on 24 to ensure that the new macro is available on all
the supported major versions.
The PG_DEPRECATED() name and location (c.h) look fine to me but maybe there is
better suggestions.
I think the way it is done in the attached makes sense, it:
- introduces PG_DEPRECATED()
- provides a use case on how to use it (i.e using a version that is currently
in the future)
- ensures that XLogRecPtrIsInvalid() deprecation is "enforced" as of version 24
- ensures that not using XLogRecPtrIsInvalid() is documented (so that it should
not be used anymore, at least in core, even waiting for version 24)
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com