Re: Safer hash table initialization macro

On Sat, Dec 6, 2025 at 3:32 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> On Fri, 5 Dec 2025 at 02:30, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > How much of our header stuff is supposed to work from C++ too?
>
> I think it's nice if it works, but it doesn't seem the most important.
> Especially since C++ has its own hashmaps. And if it really needs to
> create a hashmap it's still possible to call the.

... C functions without the helper macros. Yeah. That seems OK to me.

> > I suppose you could
> > write the typeof-based version you already hinted at, but only use it
> > for __cplusplus__ (where typeof exists as decltype).
>
> I tried to figure something out that would work in C++ (with help of
> Claude), but I wasn't able to create a version of the macros without
> also needing to add:
>
> #ifdef __cplusplus
> }
> #include <type_traits>
> extern "C" {
> #endif
>
> It seems quite ugly to escape the extern "C" from the parent like that
> and then re-enter it. Overall it doesn't seem worth the hassle to me
> to make these macros work in C++.

Yeah. I don't think we want that sort of thing all over the place.
We could eventually come up with a small set of tools in a central
place though, so people can work with this stuff without also known
C++ meta-programming voodoo. For example something like (untested, I
didn't think about char[size], just spitballing here...):

(pg_expr_has_type_p(ptr, char *) || pg_expr_has_type_p(ptr, NameData *))

... given the definition I posted recently[1].

I take your point that it's not really important for this case though.

> > Another consideration is what impact we have on the Rust world, and
> > potentially other languages used for extensions that call C via FFI
> > etc
>
> FFI generally cannot call macros anyway, only actual symbols.

Sure, I was just thinking about how such cross-language usage would be
forced to unpick our macrology and call the underlying C functions
without them. Doesn't seem like the end of the world anyway, I was
just thinking out loud about the consequences of this phenomenon in
headers.

[1] https://www.postgresql.org/message-id/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com