Horton

Re: Consistently use the XLogRecPtrIsInvalid() macro

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>, Quan Zongliang <quanzongliang@yeah.net>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-31T12:19:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Replace literal 0 with InvalidXLogRecPtr for XLogRecPtr assignments

  2. Replace pointer comparisons and assignments to literal zero with NULL

  3. Use XLogRecPtrIsValid() in various places

  4. Introduce XLogRecPtrIsValid()

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.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)