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
