Re: Consistently use the XLogRecPtrIsInvalid() macro - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Consistently use the XLogRecPtrIsInvalid() macro
Date
Msg-id f95fb1eb-ba58-469c-acc1-24ffb5a1e0f9@eisentraut.org
Whole thread Raw
In response to Re: Consistently use the XLogRecPtrIsInvalid() macro  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Consistently use the XLogRecPtrIsInvalid() macro
List pgsql-hackers
On 28.10.25 13:33, Bertrand Drouvot wrote:
> I do prefer to introduce XLogRecPtrIsValid(x) and switch to that. Then, do the
> same kind of work on OidIsValid() and TransactionIdIsValid() and add an annual
> check.
> 
> Idea is to get some code consistency while keeping macros which are valuable for
> readability and centralize changes if any need to be done in the way we check
> their validity.

If we wanted real type safety, we could turn XLogRecPtr back into a 
struct, and then enforce the use of XLogRecPtrIsValid() and similar. 
Otherwise, we should just acknowledge that it's an integer and use 
integer code to deal with it.  These *IsValid() and similar macros that 
are there for "readability" but are not actually enforced other than by 
some developers' willpower are just causing more work and inconsistency 
in the long run.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Next
From: "Joel Jacobson"
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue