Re: Making type Datum be 8 bytes everywhere

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Making type Datum be 8 bytes everywhere
Date: 2025-08-12 06:30:43
Message-ID: 01c1aae3-bc85-45d2-8866-f98816134370@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.08.25 18:44, Tom Lane wrote:
> I've now fleshed out the patch series with some cleanup of code that's
> been rendered dead.

These patches look mechanically correct to me.

For patch 0002:

The various additional uses of *GetDatum and DatumGet* could be applied
as a separate patch. That would make the remaining patch clearer as
mostly just removing dead code.

In tupmacs.h, I think the two sites with

case sizeof(Datum):

should be rewritten using

case sizeof(int64):

to match the other cases. Otherwise, this code ends up looking
mysteriously asymmetric. (And the related code in pg_type.c as well.)

The remaining mentions of "SIZEOF_DATUM" in gistproc.c and network.c
could be replaced by "sizeof(Datum)". Then we could eventually remove
SIZEOF_DATUM altogether. (Maybe DatumBigEndianToNative() would better
live in a different header file at that point, not sure.)

For patch 0003:

I would also remove most of the remaining uses of FLOAT8PASSBYVAL,
especially where it is used in relation with INT8OID, which is just
endlessly confusing.

We should also get rid of these things in the control file and the ABI
magic structs, but that could be done as separate patches. It would
probably require a separate round of thinking about compatibility,
upgrading, etc.

I'm also thinking, as a follow-on project, we could get rid of typbyval
and require that typbyval == (typlen > 0 && typlen <= 8). Something to
think about.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2025-08-12 06:34:46 Re: Parallel Apply
Previous Message Kirill Reshke 2025-08-12 06:26:12 Re: VM corruption on standby