Re: Make copyObject work in C++

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Thomas Munro <thomas.munro@gmail.com>
Date: 2026-03-09T08:39:38Z
Lists: pgsql-hackers
On 06.03.26 10:23, Peter Eisentraut wrote:
> On 02.03.26 11:56, Peter Eisentraut wrote:
>> On 27.02.26 17:40, Jelte Fennema-Nio wrote:
>>> On Fri Feb 20, 2026 at 10:47 AM CET, Jelte Fennema-Nio wrote:
>>>> Makes total sense, I didn't realise decltype and typeof were not quite
>>>> the same thing. Attached is an updated patchset that does that.
>>>
>>> Same patchset as before, but now also including a C++ fallback for
>>> __builtin_types_compatible_p.
>>
>> I have committed v10-0001.  Now let's give the buildfarm a few days.
> 
> I have committed v10-0002 and v10-0003 now.  I will look at the 
> remaining patch in a few days.

Thoughts on v10-0004:

It's not clear to me to what extent StaticAssertVariableIsOfType would 
be useful in C++.  There are two general areas where it is used.  One, 
when multiple separate extensions want to talk to each other, to check 
the types of certain entry point variables, such as 
plpython/hstore_plpython.  And two, in some macro-based template 
libraries such as lib/ilist.h and lib/pairingheap.h.  You add a lot of 
tests, but do they cover these particular use scenarios?

In either case, it might be better to create a test on that level and 
then see what we'd need to make happen to have it working under C++. 
There is lots of trickery involved there, so it's not clear whether it 
works out of the box in C++ already.

Are there any of these that you are particularly interested in for your 
work?

About the specific implementation, I'm hesitant to build this on top of 
__builtin_types_compatible_p().  Aside from the ugliness of redefining a 
symbol that starts with __builtin_*, I think we should really work to 
get rid of __builtin_types_compatible_p() and replace it with _Generic, 
which would be portable beyond GCC.

How about we make a pg_types_compatible_p(), which would look like this:

#if defined(__cplusplus)

// your C++ code here

#else if defined(HAVE__GENERIC)

// C code using _Generic here

#else

// C code using __builtin_types_compatible_p here

#endif

We can require that a supported C compiler must support either _Generic 
or __builtin_types_compatible_p, so we don't need any further fallback. 
(So we could remove the configure test of __builtin_types_compatible_p, 
but we'd add one for _Generic.)  And in a few years we could even remove 
the __builtin_types_compatible_p fallback.




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Enable test_cplusplusext with MSVC

  2. Disable some C++ warnings in MSVC

  3. meson: Make room for C++-only warning flags for MSVC

  4. Make fixed-length list building macros work in C++

  5. Make unconstify and unvolatize use StaticAssertVariableIsOfTypeMacro

  6. Use typeof everywhere instead of compiler specific spellings

  7. Test List macros in C++ extensions

  8. Test most StaticAssert macros in C++ extensions

  9. Revert "Change copyObject() to use typeof_unqual"

  10. Fix for C++ compatibility

  11. tests: Add a test C++ extension module