Re: Consistently use the XLogRecPtrIsInvalid() macro

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>

To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>

Cc: Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>, Quan Zongliang <quanzongliang@yeah.net>, pgsql-hackers@lists.postgresql.org

Date: 2025-10-30T13:55:51Z

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 30.10.25 10:17, Bertrand Drouvot wrote:
> - 0002 deprecates XLogRecPtrIsInvalid(): it emits a warning message at compilation
> time if XLogRecPtrIsInvalid() is in use in the code base.

Surely this could be factored out in macro in such a way that the 
warning message is a macro argument and we could reuse this attribute 
elsewhere in the code.

That said, I'm suspicious about marking things deprecated before the 
replacement is widely available.  If an extension has been using 
XLogRecPtrIsInvalid() until now (which has been best practice), when 
that extension adds PG19 support, they will either have to backport 
XLogRecPtrIsValid or turn off deprecation warnings.  At least there 
should be some guidance about what you expect third-party code to do 
about this.