Re: Making type Datum be 8 bytes everywhere
От | Peter Eisentraut |
---|---|
Тема | Re: Making type Datum be 8 bytes everywhere |
Дата | |
Msg-id | 44187670-73cd-46f1-a3c8-e9f52593549e@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
|
Список | pgsql-hackers |
On 30.07.25 18:06, Tom Lane wrote: > Right, we have for a long time not worried about whether VARDATA and > the allied macros are being fed a pointer or a Datum. I recall that > somebody tried to make those macros into static inlines awhile back, > and failed because of the lack of clarity about how to declare their > arguments. I don't know if that was me, but I have posted a patch about this now: https://www.postgresql.org/message-id/928ea48f-77c6-417b-897c-621ef16685a6%40eisentraut.org > I think the way forward here is to tackle that head-on > and split the top-level macros into two static inlines, along the > lines of > VARDATA(Pointer ptr) > and > VARDATA_D(Datum dat) > where the _D versions are simply DatumGetPointer and then call the > non-D versions. > > 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. There is precedent for having two different functions, though, like att_addlength_pointer() and att_addlength_datum().
В списке pgsql-hackers по дате отправления: