Re: Safer hash table initialization macro - Mailing list pgsql-hackers

Hi,

On Mon, Dec 08, 2025 at 11:53:02AM +0100, Jelte Fennema-Nio wrote:
> On Sat Dec 6, 2025 at 1:56 AM CET, Thomas Munro wrote:
> > On Sat, Dec 6, 2025 at 3:32 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > > On Fri, 5 Dec 2025 at 02:30, Thomas Munro <thomas.munro@gmail.com> wrote:
> > > create a hashmap it's still possible to call the.
> > 
> > ... C functions without the helper macros.
> 
> Oops, forgot to finish that sentence.

Thanks for this patch series!

> > 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].

+#if defined(__cplusplus)
+#define pg_expr_has_type_p(expr, type) (std::is_same<decltype(expr), type>::value)
+#else
+#define pg_expr_has_type_p(expr, type) \
+       _Generic((expr), type: 1, default: 0)
+#endif

What about relying on the existing __builtin_types_compatible_p() instead of
_Generic() here? 

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com