Re: Making type Datum be 8 bytes everywhere

Hi,

On 2025-07-17 20:09:57 -0400, Tom Lane wrote:
> In a discussion on Discord (in the PG #core-hacking channel,
> which unfortunately is inaccessible to non-members), Andres
> and Robert complained about the development/maintenance costs
> of continuing to support 32-bit platforms. Here is a modest
> proposal to reduce those costs without going so far as to
> entirely desupport such platforms: let's require them to use
> 8-byte Datums even though that's probably not a native data
> type for them. That lets us get rid of logic to support the
> !USE_FLOAT8_BYVAL case, and allows a few other simplifications.
>
> The attached patch switches to 8-byte Datums everywhere, but
> doesn't make any effort to remove the now-dead code.

Thanks for writing that!

> I made it just as a proof-of-concept that this can work. It compiled
> cleanly and passed check-world for me on a 32-bit FreeBSD image.

Interestingly it generates a *lot* of warnings here when building for 32 bit
with gcc. One class of complaints is about DatumGetPointer() and
PointerGetDatum() casting between different sizes:

../../../../../home/andres/src/postgresql/src/include/postgres.h: In function 'DatumGetPointer':
../../../../../home/andres/src/postgresql/src/include/postgres.h:320:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
320 | return (Pointer) X;
| ^
../../../../../home/andres/src/postgresql/src/include/postgres.h: In function 'PointerGetDatum':
../../../../../home/andres/src/postgresql/src/include/postgres.h:330:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
330 | return (Datum) X;
| ^

And then there's a set of complains due to code converting from NULL to Datum
without going through PointerGetDatum():
../../../../../home/andres/src/postgresql/src/include/access/htup_details.h: In function 'fastgetattr':
../../../../../home/andres/src/postgresql/src/include/access/htup_details.h:887:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
887 | return (Datum) NULL;

../../../../../home/andres/src/postgresql/src/include/access/itup.h: In function 'index_getattr':
../../../../../home/andres/src/postgresql/src/include/access/itup.h:157:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
157 | return (Datum) NULL;

A third, not quite as verbose set is random code in .c files missing uses of
DatumGetPointer(). There are lot of those.

A fourth class is passing a Datum to VAR* macros. They're a bit too verbose to
paste here, but it's just a variation of the above. I'm not really sure what
our intended use of them is, do we intend to pass pointers or datums to the
macros? I suspect we'd have to move the casts into the varlena macros,
otherwise we'll have to add DatumGetPointer() uses all over.

One of these days I should again try the experiment of making Datum into a
struct, to automatically catch omissions of datum <-> native type. Having them
be silent most of the time really sucks. I suspect that if we get the
64bit-datum-on-32bit-platform code to be warning-free, it'd get a lot easier
to struct-ify Datum. I don't recall the details, but I suspect that all the
varlena macros etc were the problem with that.

> I've not looked into the performance consequences. We probably
> should at least try to measure that, though I'm not sure what
> our threshold of pain would be for deciding not to do this.

From my POV the threshold would have to be rather high for backend code. Less
so in libpq, but that's not affected here.

Greetings,

Andres Freund