Re: Making type Datum be 8 bytes everywhere

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Making type Datum be 8 bytes everywhere
Дата
Msg-id 01c1aae3-bc85-45d2-8866-f98816134370@eisentraut.org
обсуждение исходный текст
Ответ на Re: Making type Datum be 8 bytes everywhere  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Making type Datum be 8 bytes everywhere
Re: Making type Datum be 8 bytes everywhere
Список 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.




В списке pgsql-hackers по дате отправления: