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 →
-
Enable test_cplusplusext with MSVC
- c05ad248f99c 19 (unreleased) landed
-
Disable some C++ warnings in MSVC
- 82a7cbea747c 19 (unreleased) landed
-
meson: Make room for C++-only warning flags for MSVC
- 4c83f1253593 19 (unreleased) landed
-
Make fixed-length list building macros work in C++
- f8e7ca328510 19 (unreleased) landed
-
Make unconstify and unvolatize use StaticAssertVariableIsOfTypeMacro
- 258248d0bdbf 19 (unreleased) landed
-
Use typeof everywhere instead of compiler specific spellings
- e2308350c9b7 19 (unreleased) landed
-
Test List macros in C++ extensions
- 3d28ecb5ac76 19 (unreleased) landed
-
Test most StaticAssert macros in C++ extensions
- 451650eaacd5 19 (unreleased) landed
-
Revert "Change copyObject() to use typeof_unqual"
- 0af05b5dbb42 19 (unreleased) landed
-
Fix for C++ compatibility
- b4555cb070f1 19 (unreleased) landed
-
tests: Add a test C++ extension module
- 476b35d4e311 19 (unreleased) landed