Re: Consistently use the XLogRecPtrIsInvalid() macro

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Álvaro Herrera <alvherre@kurilemu.de>, 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-19T17:53:31Z

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 →

Replace literal 0 with InvalidXLogRecPtr for XLogRecPtr assignments
- ec3174407164 19 (unreleased) landed
Replace pointer comparisons and assignments to literal zero with NULL
- ec782f56b0c3 19 (unreleased) landed
Use XLogRecPtrIsValid() in various places
- a2b02293bc65 19 (unreleased) landed
Introduce XLogRecPtrIsValid()
- d2965f627fe3 14.20 landed
- c0031d461324 18.1 landed
- 723cc84db50a 16.11 landed
- 49b45999f3b2 15.15 landed
- 33727aff18d0 17.7 landed
- 20bafb097288 13.23 landed
- 06edbed47862 19 (unreleased) landed

On 2025-11-19 12:27:30 -0500, Robert Haas wrote:
> It's possible, but fundamentally I think it's about replacing
> XLogRecPtrIsInvalid with XLogRecPtrIsValid, and what I'm saying is I
> wouldn't have chosen to do that. I agree that it would have been
> better to do it that way originally, but I disagree with paying the
> switching cost, especially in the back-branches.

+1

This just seems like a lot of noise for something at most very mildly odd.