From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | 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-07-31 14:17:06 |
Message-ID: | 44187670-73cd-46f1-a3c8-e9f52593549e@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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().
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2025-07-31 14:19:48 | Re: log_min_messages per backend type |
Previous Message | Peter Eisentraut | 2025-07-31 14:13:10 | Re: Making type Datum be 8 bytes everywhere |