Re: Making type Datum be 8 bytes everywhere - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making type Datum be 8 bytes everywhere
Date
Msg-id 2073720.1753972057@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making type Datum be 8 bytes everywhere  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Making type Datum be 8 bytes everywhere
List pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> On 30.07.25 18:06, Tom Lane wrote:
>> I'm giving the traditional names to the Pointer variants because it
>> turns out that way more places would have to change if we do it the
>> other way: in a rough count, about 50 versus about 1700.  (This is
>> counting only the core backend.)  Beyond that, though, bikeshedding
>> on the naming is welcome.

> In my patch, I just added the missing DatumGetPointer() calls, which 
> seemed easy enough.

I had an earlier patch version that also did that, but it seemed
kind of verbose to me: adding "_D" is much shorter than adding
"DatumGetPointer()", and fewer parens seems good for readability.

One interesting thing I noted is that in some modules we already
were applying DatumGetPointer where needed (mostly, at least).
The patch I just posted in your other thread also simplifies those
cases to use the "_D" notation, which makes it longer than strictly
necessary.  But I think consistency of notation is good.

> There is precedent for having two different functions, though, like 
> att_addlength_pointer() and att_addlength_datum().

Yeah ... those two macros could stand to be cleaned up too, per
the notes in their comments.  But I don't think we need to fix
that today.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET
Next
From: Peter Eisentraut
Date:
Subject: Re: Making type Datum be 8 bytes everywhere