Re: Convert varatt.h macros to static inline functions

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-31T23:40:33Z
Lists: pgsql-hackers
On Thu, Jul 31, 2025 at 10:06:02AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
> > I had this lying around as a draft patch, as part of my ongoing campaign 
> > to convert many complicated macros to static inline functions.  Since 
> > the topic was mentioned in another thread [0], I cleaned up the patch so 
> > that we can all look at it.
> 
> I had just finished doing exactly that, per my idea in the other
> thread of providing both pointer and Datum variants where needed.
> I'll look more closely at yours in a bit, but here's mine.

I'm finding that your wip version is bit more complete as you have
introduced inline functions for these ones:
- VARATT_EXTERNAL_GET_EXTSIZE()
- VARATT_EXTERNAL_GET_COMPRESS_METHOD(). 

Another comment that can apply to all the patches presented on this
thread.  Could it be worth splitting these inline functions into a
separate header that declares varatt.h, meaning that we'd need to
think a bit more about the structures themselves and all the
sub-macros like SET_VARSIZE_1B() & friends?  There is a bit of chaos
that has accumulated in varatt.h over the ages, still there is a
hierarchy with the most "internal" structures and what gets used by
the code C code.  So we could use this occasion to split things if
that brings some clarity..
--
Michael

Commits

  1. Suppress maybe-uninitialized warning.

  2. Convert varatt.h access macros to static inline functions.

  3. Fix varatt versus Datum type confusions