Thread

Re: Safer hash table initialization macro

Thomas Munro <thomas.munro@gmail.com> — 2025-12-05T01:29:48Z

On Fri, Dec 5, 2025 at 4:30 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I'm a bit on the fence about the C11 _Generic code to determine whether
> we should use HASH_BLOBS or HASH_STRINGS based on the type of the key.
> It works really nicely in practice, but I'm worried it's a bit too much
> magic. Probably we should at least have an override to allow using
> HASH_BLOBS anyway for a char array (in case it's not null terminated).

How much of our header stuff is supposed to work from C++ too?  I
assume that if this is passing cpluspluscheck then it's only because
those _Generic macros aren't being expanded.  I suppose you could
write the typeof-based version you already hinted at, but only use it
for __cplusplus__ (where typeof exists as decltype).

What I mean is, if something like DuckDB (C++ IIRC) wants to actually
use these APIs with the new interfaces, they won't work if the macros
expant to _Generic (not legal C++), but a typeof/decltype-based
version should work just fine, but at the same time I don't think
we'd want to use typeof just because it is available, or we'd never
test the _Generic version: all 3 C compilers have something we can use
for typeof, it's just not standard C before C23, and we want
PostgreSQL to be a valid C11 program and actually have coverage of
those code branches.

Another consideration is what impact we have on the Rust world, and
potentially other languages used for extensions that call C via FFI
etc, if we start using _Generic in our public interfaces, as opposed
to just using it in smaller ways as part of our internal assertions
and C implementation code that doesn't affect extensions.  Of course
people using C APIs have to deal with the complexities of C evolution
too, I'm not saying that's a blocker, I'm just trying to think through
the impact of these sorts of API changes on the ecosystem.