Horton

Re: Consistently use the XLogRecPtrIsInvalid() macro

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, 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-11-19T16:14:53Z
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 Thu, Nov 6, 2025 at 2:48 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> Okay, thanks, I have applied that one to all stable branches, except I
> didn't add the judgemental comment about XLogRecPtrIsInvalid().

I'm rather late to the party here, but for what it's worth, I don't
really think this was a good idea. Anyone who wants to write
out-of-core code that works in the back-branches must still write it
the old way, or it will potentially fail on older minor releases. Over
the alternative actually chosen, I would have preferred (a) not doing
this project at all or (b) making a hard switch in master to use the
new macro everywhere and remove the old one, while leaving the
back-branches unchanged or (c) dropping the use of the macro
altogether, in that order of preference.

That sad, I'm not arguing for a revert. My basic position is that this
wasn't worth the switching cost, not that it was intrinsically a bad
idea.

-- 
Robert Haas
EDB: http://www.enterprisedb.com