Horton
Menu

Thread

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

  1. Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-05T14:46:57Z

    Calling copyObject fails in C++ with an error like in most setups:

error: use of undeclared identifier 'typeof'; did you mean 'typeid'

This is due to the C compiler supporting used to compile postgres
supporting typeof, but that function actually not being present in the
C++ compiler. This fixes that by using decltype instead of typeof when
including the header in C++.

Realized because of Thomas' not about how much of our headers should
work in C++, and remembering I hit this specific problem myself.

Another approach would be to force the value of HAVE_TYPEOF to 0 if __cplusplus.

  2. Re: Make copyObject work in C++

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-07T19:45:07Z

    Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> Calling copyObject fails in C++ with an error like in most setups:
> error: use of undeclared identifier 'typeof'; did you mean 'typeid'
> This is due to the C compiler supporting used to compile postgres
> supporting typeof, but that function actually not being present in the
> C++ compiler. This fixes that by using decltype instead of typeof when
> including the header in C++.

Hmm, this only fixes the one use-case.  Admittedly we have only one
use-case, but as soon as we have another we'll have a new problem.
How about instead modifying the macro?  Maybe something like this
in c.h (untested):

#ifdef __cplusplus
#undef typeof
#define typeof decltype
#define HAVE_TYPEOF 1
#endif

> Another approach would be to force the value of HAVE_TYPEOF to 0 if __cplusplus.

That would be sad, because we'd lose the type checking ability
of copyObject() in C++ code.

BTW, grepping finds a number of random references to __typeof__ and
__typeof, which probably ought to be updated to be just typeof.

			regards, tom lane

  3. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-08T07:57:17Z

    On 05.12.25 15:46, Jelte Fennema-Nio wrote:
> Calling copyObject fails in C++ with an error like in most setups:
> 
> error: use of undeclared identifier 'typeof'; did you mean 'typeid'
> 
> This is due to the C compiler supporting used to compile postgres
> supporting typeof, but that function actually not being present in the
> C++ compiler. This fixes that by using decltype instead of typeof when
> including the header in C++.
> 
> Realized because of Thomas' not about how much of our headers should
> work in C++, and remembering I hit this specific problem myself.
> 
> Another approach would be to force the value of HAVE_TYPEOF to 0 if __cplusplus.

In the long run, I would like to change copyObject() to use 
typeof_unqual instead, because that handles qualifiers more correctly. 
(Currently, copyObject() of a const-qualified pointer results in a 
const-qualified pointer, which is nonsensical because the reason you 
made the copy is that you can modify it.)  See attached patch for an 
example.  Does C++ have something that is semantically similar to that?

  4. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-08T08:00:55Z

    On 07.12.25 20:45, Tom Lane wrote:
> Hmm, this only fixes the one use-case.  Admittedly we have only one
> use-case, but as soon as we have another we'll have a new problem.
> How about instead modifying the macro?  Maybe something like this
> in c.h (untested):
> 
> #ifdef __cplusplus
> #undef typeof
> #define typeof decltype
> #define HAVE_TYPEOF 1
> #endif

AFAICT, both gcc and clang support typeof in C++ mode as well.  So this 
kind of renaming could be confusing.

  5. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-08T08:11:59Z

    On Sun Dec 7, 2025 at 8:45 PM CET, Tom Lane wrote:
> #ifdef __cplusplus
> #undef typeof
> #define typeof decltype
> #define HAVE_TYPEOF 1
> #endif

Went with defining pg_exprtype (pg_typeof already exists). Undefining
typeof seemed a bit heavy-handed. Especially since I think it would be
nice to backport this so C++ extensions can use copyObject directly.

> BTW, grepping finds a number of random references to __typeof__ and
> __typeof, which probably ought to be updated to be just typeof.

Added a follow on patch that starts using pg_exrtype in all those
places.

  6. Re: Make copyObject work in C++

    David Geier <geidav.pg@gmail.com> — 2025-12-08T08:33:10Z

    On 08.12.2025 08:57, Peter Eisentraut wrote:
> On 05.12.25 15:46, Jelte Fennema-Nio wrote:
>> Calling copyObject fails in C++ with an error like in most setups:
>>
>> error: use of undeclared identifier 'typeof'; did you mean 'typeid'
>>
>> This is due to the C compiler supporting used to compile postgres
>> supporting typeof, but that function actually not being present in the
>> C++ compiler. This fixes that by using decltype instead of typeof when
>> including the header in C++.
>>
>> Realized because of Thomas' not about how much of our headers should
>> work in C++, and remembering I hit this specific problem myself.
>>
>> Another approach would be to force the value of HAVE_TYPEOF to 0 if
>> __cplusplus.
> 
> In the long run, I would like to change copyObject() to use
> typeof_unqual instead, because that handles qualifiers more correctly.
> (Currently, copyObject() of a const-qualified pointer results in a
> const-qualified pointer, which is nonsensical because the reason you
> made the copy is that you can modify it.)  See attached patch for an
> example.  Does C++ have something that is semantically similar to that?

Since C++11 there's std::remove_const which can be used as
std::remove_const<decltype(type)>::type.

I'm not aware of anything pre C++11, except for rolling your own variant
of std::remove_const via template specialization.

--
David Geier

  7. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-08T08:52:17Z

    On Mon, 8 Dec 2025 at 09:33, David Geier <geidav.pg@gmail.com> wrote:
> Since C++11 there's std::remove_const which can be used as
> std::remove_const<decltype(type)>::type.
>
> I'm not aware of anything pre C++11, except for rolling your own variant
> of std::remove_const via template specialization.

I think depending on C++11 sounds fine, since we're also depending on
C11 and people tend to use much more recent C++ versions than C
versions (so probably we could even require something higher).

  8. Re: Make copyObject work in C++

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-08T14:51:06Z

    Peter Eisentraut <peter@eisentraut.org> writes:
> AFAICT, both gcc and clang support typeof in C++ mode as well.  So this 
> kind of renaming could be confusing.

Hm, if that's true then we should not have to do anything ...
so why is Jelte reporting a problem?

			regards, tom lane

  9. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-08T15:31:30Z

    On Mon, 8 Dec 2025 at 15:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter@eisentraut.org> writes:
> > AFAICT, both gcc and clang support typeof in C++ mode as well.  So this
> > kind of renaming could be confusing.
>
> Hm, if that's true then we should not have to do anything ...
> so why is Jelte reporting a problem?

Seems it's related to -std=c++17 vs -std=gnu++17. I was compiling my
code with the former, which throws the error in question[1]. Compiling
with the latter works fine[2].

So I guess it depends what we want to require from C++ extensions.
Should we require them to compile with gnu extensions? My opinion on
that would be no.

[1]: https://godbolt.org/z/fz567hs1r
[2]: https://godbolt.org/z/cq1se55bn

  10. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-09T12:58:40Z

    On Mon, 8 Dec 2025 at 08:57, Peter Eisentraut <peter@eisentraut.org> wrote:
> In the long run, I would like to change copyObject() to use
> typeof_unqual instead, because that handles qualifiers more correctly.
> (Currently, copyObject() of a const-qualified pointer results in a
> const-qualified pointer, which is nonsensical because the reason you
> made the copy is that you can modify it.)  See attached patch for an
> example.  Does C++ have something that is semantically similar to that?

Yes, there's a std::remove_cv, std::remove_const, and std::remove_volatile[1].

[1]: https://en.cppreference.com/w/cpp/types/remove_cv.html

  11. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2025-12-14T16:56:23Z

    On Mon Dec 8, 2025 at 9:11 AM CET, Jelte Fennema-Nio wrote:
> Went with defining pg_exprtype (pg_typeof already exists). Undefining
> typeof seemed a bit heavy-handed. Especially since I think it would be
> nice to backport this so C++ extensions can use copyObject directly.

Rebased version of this patchset after conflicts from 315342ffed.

  12. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-16T12:28:27Z

    On 05.12.25 15:46, Jelte Fennema-Nio wrote:
> Calling copyObject fails in C++ with an error like in most setups:
> 
> error: use of undeclared identifier 'typeof'; did you mean 'typeid'
> 
> This is due to the C compiler supporting used to compile postgres
> supporting typeof, but that function actually not being present in the
> C++ compiler. This fixes that by using decltype instead of typeof when
> including the header in C++.
> 
> Realized because of Thomas' not about how much of our headers should
> work in C++, and remembering I hit this specific problem myself.

I think it might be good to create a test extension written in C++, like 
under src/test/modules/, and sprinkle it with various constructs like 
copyObject() and static assertions, and whatever else we find that is 
possibly problematic.  Then patches like this one would be much easier 
to analyze and test and keep working in the future.

This would probably require resolving 
<https://commitfest.postgresql.org/patch/5885/> first.

  13. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-03T09:32:28Z

    On Tue Dec 16, 2025 at 1:28 PM CET, Peter Eisentraut wrote:
> I think it might be good to create a test extension written in C++, like 
> under src/test/modules/, and sprinkle it with various constructs like 
> copyObject() and static assertions, and whatever else we find that is 
> possibly problematic.

Attached is a patchset that does that. It required a few more fixes to
make the extension compile on MSVC too.

  14. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-10T11:09:10Z

    On Sat Jan 3, 2026 at 10:32 AM CET, Jelte Fennema-Nio wrote:
> Attached is a patchset that does that. It required a few more fixes to
> make the extension compile on MSVC too.

Rebased after Peter merged the C++ improvements from the other thread.

  15. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-14T15:59:55Z

    On 10.01.26 12:09, Jelte Fennema-Nio wrote:
> On Sat Jan 3, 2026 at 10:32 AM CET, Jelte Fennema-Nio wrote:
>> Attached is a patchset that does that. It required a few more fixes to
>> make the extension compile on MSVC too.
> 
> Rebased after Peter merged the C++ improvements from the other thread.

I have a couple of comments on the sample extension module.

I think this module should have a runtime test, too.  Otherwise you 
don't know that you got the linkage correct, or whether this works at 
all.  It doesn't have to do much, like it could literally be a + b, and 
it could evolve in the future to test hooks, _PG_init, etc.

Let's put a README file in the module's directory instead of putting the 
explanation into the Makefile/meson.build.

I wonder if the module's build integration would work correctly in the 
autoconf/makefile case if no C++ is available.  AFAICT, it would fail to 
build with g++ not found or similar.

AFAICT, the minimum changes to get a minimum test module to work are

- fix for "restrict", recently committed
- disable warning about zero-length arrays, seems trivial
- named designated initializers

I learned that named designated initializers in C++ are not allowed to 
be specified out of order, so they are not a full equivalent to the C 
syntax.  This could be a problem for example if someone wanted in the 
future to have something like

     PG_MODULE_MAGIC_EXT(.threads_supported = true)

(while not specifying the leading .name and .version fields).

I think for now the easiest fix would be to just not use the named 
initializers in the definition of PG_MODULE_MAGIC_DATA.  Then we don't 
need to require C++20 and have that additional code.  In the future, we 
might need a different solution more suitable for C++.

The use of -std=c++11 for CI is a valid idea; I have often wanted that 
for C as well.  But conversely we also want to allow testing optional 
extension and future C standard features.  So we need a comprehensive 
solution there that covers both ends and both languages.  Let's leave 
that out for now and think about it separately.

  16. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-17T15:25:51Z

    On Wed, 14 Jan 2026 at 16:59, Peter Eisentraut <peter@eisentraut.org> wrote:
> I think this module should have a runtime test, too.  Otherwise you
> don't know that you got the linkage correct, or whether this works at
> all.  It doesn't have to do much, like it could literally be a + b, and
> it could evolve in the future to test hooks, _PG_init, etc.

Done 

> Let's put a README file in the module's directory instead of putting the
> explanation into the Makefile/meson.build.

Done 

> I wonder if the module's build integration would work correctly in the
> autoconf/makefile case if no C++ is available.  AFAICT, it would fail to
> build with g++ not found or similar.

Changed this to check that if CXX is g++, the command is also actually
available before including the module for the build.

> AFAICT, the minimum changes to get a minimum test module to work are
>
> - fix for "restrict", recently committed
> - disable warning about zero-length arrays, seems trivial
> - named designated initializers

Correct, I've now restructured the commits to have the module
introduction as the first one. Then all the other commits, both fix a
macro to work in C++ and add some usage of those macros as coverage to
the previously added module.

> I learned that named designated initializers in C++ are not allowed to
> be specified out of order, so they are not a full equivalent to the C
> syntax.  This could be a problem for example if someone wanted in the
> future to have something like
>
>      PG_MODULE_MAGIC_EXT(.threads_supported = true)
>
> (while not specifying the leading .name and .version fields).

This would still work fine, because fields are left out. The problem
occurs when defining values for fields, but in a different order than
the fields are specified in the struct (so e.g. by putting .version
before .name). The reason for that is related to destructor ordering.

> I think for now the easiest fix would be to just not use the named
> initializers in the definition of PG_MODULE_MAGIC_DATA.  Then we don't
> need to require C++20 and have that additional code.  In the future, we
> might need a different solution more suitable for C++.

There is a small problem with this though. Using both designated an
non-designated initializers, is not valid standard C++. I even get a
warning (but no error) about that with clang:

../src/test/modules/test_cplusplusext/test_cplusplusext.cpp:24:2: warning: mixture of designated and non-designated initializers in the same initializer list is a C99 extension [-Wc99-designator]

In C mixing them is allowed just fine.

Sadly that means that C++ extensions (even when compiled for C++20)
shouldn't use PG_MODULE_MAGIC_EXT with designated initializers at all.
I've updated the documentation to reflect that. I agree that it's better
to avoid requiring C++20 on MSVC (at least for now).

> The use of -std=c++11 for CI is a valid idea; I have often wanted that
> for C as well.  But conversely we also want to allow testing optional
> extension and future C standard features.  So we need a comprehensive
> solution there that covers both ends and both languages.  Let's leave
> that out for now and think about it separately.

Removed

  17. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-20T16:28:00Z

    On 17.01.26 16:25, Jelte Fennema-Nio wrote:
>> AFAICT, the minimum changes to get a minimum test module to work are
>>
>> - fix for "restrict", recently committed
>> - disable warning about zero-length arrays, seems trivial
>> - named designated initializers
> 
> Correct, I've now restructured the commits to have the module
> introduction as the first one. Then all the other commits, both fix a
> macro to work in C++ and add some usage of those macros as coverage to
> the previously added module.

I have split your first patch further.  For a start, I left out the 
PG_MODULE_MAGIC*-related changes and disabled the module under MSVC. 
This has been committed.  I plan to let the buildfarm run with it for a 
day or two and then add in the basic MSVC support.

I implemented a different solution for checking whether C++ is available 
under configure.  The runtime check from the makefile looked a bit 
fragile.  This way, we now have a "have_cxx" variable available in both 
meson and makefiles.

  18. Re: Make copyObject work in C++

    Andres Freund <andres@anarazel.de> — 2026-01-20T16:38:29Z

    On 2026-01-20 17:28:00 +0100, Peter Eisentraut wrote:
> On 17.01.26 16:25, Jelte Fennema-Nio wrote:
> > > AFAICT, the minimum changes to get a minimum test module to work are
> > >
> > > - fix for "restrict", recently committed
> > > - disable warning about zero-length arrays, seems trivial
> > > - named designated initializers
> >
> > Correct, I've now restructured the commits to have the module
> > introduction as the first one. Then all the other commits, both fix a
> > macro to work in C++ and add some usage of those macros as coverage to
> > the previously added module.
>
> I have split your first patch further.  For a start, I left out the
> PG_MODULE_MAGIC*-related changes and disabled the module under MSVC. This
> has been committed.  I plan to let the buildfarm run with it for a day or
> two and then add in the basic MSVC support.

Seems like billbug doesn't like this:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=billbug&dt=2026-01-20%2016%3A00%3A02

gmake[1]: Entering directory '/home/marcel/build-farm-20/buildroot/HEAD/pgsql.build/src/test/modules/test_cplusplusext'
g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -I. -I. -I../../../../src/include -D_POSIX_C_SOURCE=200112L -D__EXTENSIONS__ -D_POSIX_PTHREAD_SEMANTICS  -I/usr/openssl/3/include -I/usr/include/libxml2     -c -o test_cplusplusext.o test_cplusplusext.cpp
In file included from ../../../../src/include/postgres.h:48,
                 from test_cplusplusext.cpp:18:
../../../../src/include/c.h:158:21: error: '_Noreturn' does not name a type; did you mean 'pg_noreturn'?
  158 | #define pg_noreturn _Noreturn
      |                     ^~~~~~~~~
../../../../src/include/c.h:918:1: note: in expansion of macro 'pg_noreturn'
  918 | pg_noreturn extern void ExceptionalCondition(const char *conditionName,
      | ^~~~~~~~~~~
../../../../src/include/lib/stringinfo.h: In function 'void initStringInfoFromString(StringInfo, char*, int)':
../../../../src/include/c.h:890:25: error: 'ExceptionalCondition' was not declared in this scope
  890 |                         ExceptionalCondition(#condition, __FILE__, __LINE__); \\
      |                         ^~~~~~~~~~~~~~~~~~~~
../../../../src/include/lib/stringinfo.h:177:9: note: in expansion of macro 'Assert'
  177 |         Assert(data[len] == '\\0');
      |         ^~~~~~
../../../../src/include/utils/elog.h: At global scope:
../../../../src/include/c.h:158:21: error: '_Noreturn' does not name a type; did you mean 'pg_noreturn'?
  158 | #define pg_noreturn _Noreturn
      |                     ^~~~~~~~~
../../../../src/include/utils/elog.h:471:1: note: in expansion of macro 'pg_noreturn'
  471 | pg_noreturn extern void ReThrowError(ErrorData *edata);
      | ^~~~~~~~~~~
../../../../src/include/c.h:158:21: error: '_Noreturn' does not name a type; did you mean 'pg_noreturn'?
  158 | #define pg_noreturn _Noreturn
      |                     ^~~~~~~~~
../../../../src/include/utils/elog.h:473:1: note: in expansion of macro 'pg_noreturn'
  473 | pg_noreturn extern void pg_re_throw(void);
      | ^~~~~~~~~~~

Greetings,

Andres Freund

  19. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-20T19:07:15Z

    On 20.01.26 17:38, Andres Freund wrote:
>> I have split your first patch further.  For a start, I left out the
>> PG_MODULE_MAGIC*-related changes and disabled the module under MSVC. This
>> has been committed.  I plan to let the buildfarm run with it for a day or
>> two and then add in the basic MSVC support.
> Seems like billbug doesn't like this:
> 
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl? 
> nm=billbug&dt=2026-01-20%2016%3A00%3A02
> 
> gmake[1]: Entering directory '/home/marcel/build-farm-20/buildroot/HEAD/pgsql.build/src/test/modules/test_cplusplusext'
> g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -I. -I. -I../../../../src/include -D_POSIX_C_SOURCE=200112L -D__EXTENSIONS__ -D_POSIX_PTHREAD_SEMANTICS  -I/usr/openssl/3/include -I/usr/include/libxml2     -c -o test_cplusplusext.o test_cplusplusext.cpp
> In file included from ../../../../src/include/postgres.h:48,
>                   from test_cplusplusext.cpp:18:
> ../../../../src/include/c.h:158:21: error: '_Noreturn' does not name a type; did you mean 'pg_noreturn'?
>    158 | #define pg_noreturn _Noreturn
>        |                     ^~~~~~~~~
> ../../../../src/include/c.h:918:1: note: in expansion of macro 'pg_noreturn'
>    918 | pg_noreturn extern void ExceptionalCondition(const char *conditionName,
>        | ^~~~~~~~~~~

It's getting confused by _Noreturn, which is defined thus:

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
#define pg_noreturn _Noreturn

But apparently on these Solaris-related platforms, g++ defines 
__STDC_VERSION__ even in C++ mode.  (Confirmed in local testing.) 
Apparently, this is even allowed by the C++ standard.

So the smallest fix is probably to gate this more like this:

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) && 
!defined(__cplusplus)
#define pg_noreturn _Noreturn

(Eventually, we could add support for C++ attributes, but one step at a 
time.)

  20. Re: Make copyObject work in C++

    Andres Freund <andres@anarazel.de> — 2026-01-20T19:15:44Z

    Hi,

On 2026-01-20 20:07:15 +0100, Peter Eisentraut wrote:
> On 20.01.26 17:38, Andres Freund wrote:
> > > I have split your first patch further.  For a start, I left out the
> > > PG_MODULE_MAGIC*-related changes and disabled the module under MSVC. This
> > > has been committed.  I plan to let the buildfarm run with it for a day or
> > > two and then add in the basic MSVC support.
> > Seems like billbug doesn't like this:
> > 
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?
> > nm=billbug&dt=2026-01-20%2016%3A00%3A02
> > 
> > gmake[1]: Entering directory '/home/marcel/build-farm-20/buildroot/HEAD/pgsql.build/src/test/modules/test_cplusplusext'
> > g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -I. -I. -I../../../../src/include -D_POSIX_C_SOURCE=200112L -D__EXTENSIONS__ -D_POSIX_PTHREAD_SEMANTICS  -I/usr/openssl/3/include -I/usr/include/libxml2     -c -o test_cplusplusext.o test_cplusplusext.cpp
> > In file included from ../../../../src/include/postgres.h:48,
> >                   from test_cplusplusext.cpp:18:
> > ../../../../src/include/c.h:158:21: error: '_Noreturn' does not name a type; did you mean 'pg_noreturn'?
> >    158 | #define pg_noreturn _Noreturn
> >        |                     ^~~~~~~~~
> > ../../../../src/include/c.h:918:1: note: in expansion of macro 'pg_noreturn'
> >    918 | pg_noreturn extern void ExceptionalCondition(const char *conditionName,
> >        | ^~~~~~~~~~~
> 
> It's getting confused by _Noreturn, which is defined thus:
> 
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
> #define pg_noreturn _Noreturn
> 
> But apparently on these Solaris-related platforms, g++ defines
> __STDC_VERSION__ even in C++ mode.  (Confirmed in local testing.)
> Apparently, this is even allowed by the C++ standard.

Heh. Pretty odd to do that only on some platforms...


> So the smallest fix is probably to gate this more like this:
> 
> #if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) &&
> !defined(__cplusplus)
> #define pg_noreturn _Noreturn
> 
> (Eventually, we could add support for C++ attributes, but one step at a
> time.)

Makes sense to me.

Greetings,

Andres Freund

  21. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-25T12:42:51Z

    On Tue Jan 20, 2026 at 5:28 PM CET, Peter Eisentraut wrote:
> I have split your first patch further.  For a start, I left out the 
> PG_MODULE_MAGIC*-related changes and disabled the module under MSVC. 
> This has been committed.  I plan to let the buildfarm run with it for a 
> day or two and then add in the basic MSVC support.

To hopefully make your life a bit easier. Here's a rebased version that
enables the MSVC support again, with an updated commit message.

  22. Re: Make copyObject work in C++

    Andres Freund <andres@anarazel.de> — 2026-01-25T16:50:28Z

    Hi,

On 2026-01-25 13:42:51 +0100, Jelte Fennema-Nio wrote:
> This reverts to using positional initializers in PG_MODULE_MAGIC_DATA so
> that its possible to write C++ extensions in standard C++11. Sadly that
> means that using designated initializers in C++20 is still not allowed
> in PG_MODULE_MAGIC_EXT because mixing designated an positional
> initializers is a C only feature. This restriction for C++ extensions is
> now documented and tested.

I'm pretty sceptical this is the right direction. We were going for designated
initializers for a reason, namely that we expect more arguments to be added
over time and perhaps eventually also to remove some. And this will just lead
to that being harder because we have to worry about C++ extensions.


But I'm also confused as to why it's needed - there's nomixing of designated
and non-designated initializers that I can see? If you use
PG_MODULE_MAGIC_EXT(.name = "whatnot"), it evaluates down to

extern __attribute__((visibility("default"))) const Pg_magic_struct *Pg_magic_func(void); const Pg_magic_struct * Pg_magic_func(void) { static const Pg_magic_struct Pg_magic_data = { .len = sizeof(Pg_magic_struct), .abi_fields = { 190000 / 100, 100, 32, 64, true, "PostgreSQL", }, .name="whatnot"}; return &Pg_magic_data; } extern int no_such_variable;

And indeed, contra to what you reported upthread, I can't get clang to report
a warning about that.  I do obviously see warnings about the wrong order if I
pass the arguments in the wrong order, but that's a lot less problematic. And
omitted args don't trigger warnings, as you noted.


Greetings,

Andres Freund

  23. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-25T17:52:37Z

    On Sun Jan 25, 2026 at 5:50 PM CET, Andres Freund wrote:
> I'm pretty sceptical this is the right direction. 

The only other option I can think of is not supporting C++ extension on
MSVC unless they are compiled with C++20 (or later). I don't
particularly care about Windows C++ extensions myself, so I personally
would be fine with that choice. It seems a bit harsh, though.

> We were going for designated
> initializers for a reason, namely that we expect more arguments to be added
> over time and perhaps eventually also to remove some. And this will just lead
> to that being harder because we have to worry about C++ extensions.

Adding new arguments (aka fields) should cause no problems. Assuming
we'd add them at the end of the Pg_magic_struct definition. Removing
ones seems like even for C you'd need different PG_MODULE_MAGIC_EXT
invocations depending on PG_VERSION_NUM. I don't see how using
positional args would make that harder.

> But I'm also confused as to why it's needed - there's nomixing of designated
> and non-designated initializers that I can see? If you use
> PG_MODULE_MAGIC_EXT(.name = "whatnot"), it evaluates down to
>
> extern __attribute__((visibility("default"))) const Pg_magic_struct *Pg_magic_func(void); const Pg_magic_struct * Pg_magic_func(void) { static const Pg_magic_struct Pg_magic_data = { .len = sizeof(Pg_magic_struct), .abi_fields = { 190000 / 100, 100, 32, 64, true, "PostgreSQL", }, .name="whatnot"}; return &Pg_magic_data; } extern int no_such_variable;
>
> And indeed, contra to what you reported upthread, I can't get clang to report
> a warning about that.  I do obviously see warnings about the wrong order if I
> pass the arguments in the wrong order, but that's a lot less problematic. And
> omitted args don't trigger warnings, as you noted.

It sounds like I wasn't clear enough what the problem was. The main
problem currently is that MSVC C++ fails to compile a cpp file
containing PG_MODULE_MAGIC (or PG_MODULE_MAGIC_EXT) unless you use /std:c++20.

Afaict it would have been possible to do so before 9324c8c580 (aka
anything before PG18), but since that commit you need /std:c++20. The
fact that we haven't heard anyone complain so far, might be an indication
that not many people (or maybe anyone) is using C++ extensions on Windows.

The only way to make PG_MODULE_MAGIC work on MSVC pre-C++20 is to
partially revert 9324c8c580, and use positional arguments in the
definition of PG_MODULE_MAGIC_DATA again. Like I've done in v7-0001.

For C extensions v7-0001 has no downsides. However, after applying
v7-0001, C++ extensions that use PG_MODULE_MAGIC_EXT with designated
parameters will get the following warning on at least clang 18 on my
machine:

meson setup --prefix ~/.pgenv/pgsql-master --debug build --reconfigure -Dc_args='-fno-omit-frame-pointer' -Dcassert=true
meson test -C build --suite setup --suite test_cplusplusext

[2202/2268] Compiling C++ object src/test/modules/test_cplusplusext/test_cplusplusext.so.p/test_cplusplusext.cpp.o
../src/test/modules/test_cplusplusext/test_cplusplusext.cpp:23:21: warning: mixture of designated and non-designated initializers in the same initializer list is a C99 extension [-Wc99-designator]
   23 | PG_MODULE_MAGIC_EXT(.name="test_cplusplusext",.version= "1.2");
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~
../src/include/fmgr.h:548:24: note: expanded from macro 'PG_MODULE_MAGIC_EXT'
  548 |                 PG_MODULE_MAGIC_DATA(__VA_ARGS__); \
      |                                      ^~~~~~~~~~~
../src/include/fmgr.h:509:2: note: expanded from macro 'PG_MODULE_MAGIC_DATA'
  509 |         __VA_ARGS__ \
      |         ^~~~~~~~~~~
../src/test/modules/test_cplusplusext/test_cplusplusext.cpp:23:1: note: first non-designated initializer is here
   23 | PG_MODULE_MAGIC_EXT(.name="test_cplusplusext",.version= "1.2");
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/include/fmgr.h:548:3: note: expanded from macro 'PG_MODULE_MAGIC_EXT'
  548 |                 PG_MODULE_MAGIC_DATA(__VA_ARGS__); \
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/include/fmgr.h:507:2: note: expanded from macro 'PG_MODULE_MAGIC_DATA'
  507 |         sizeof(Pg_magic_struct), \
      |         ^~~~~~~~~~~~~~~~~~~~~~~

Note that you need to use meson test, not meson install, otherwise
test_cplusplusext.cpp won't get compiled.

So to be clear, yes right now there's no mixing of designated and
non-designated initializers. But after applying v7-0001 there would be
when you use something like this:
PG_MODULE_MAGIC_EXT(.name="test_cplusplusext",.version= "1.2");


And while the C standard allows mixing designated and non-designated
initializerss, the C++ standard (even C++20) does not.

  24. Re: Make copyObject work in C++

    Andres Freund <andres@anarazel.de> — 2026-01-25T20:06:12Z

    Hi,

On 2026-01-25 18:52:37 +0100, Jelte Fennema-Nio wrote:
> On Sun Jan 25, 2026 at 5:50 PM CET, Andres Freund wrote:
> > We were going for designated
> > initializers for a reason, namely that we expect more arguments to be added
> > over time and perhaps eventually also to remove some. And this will just lead
> > to that being harder because we have to worry about C++ extensions.
> 
> Adding new arguments (aka fields) should cause no problems. Assuming
> we'd add them at the end of the Pg_magic_struct definition. Removing
> ones seems like even for C you'd need different PG_MODULE_MAGIC_EXT
> invocations depending on PG_VERSION_NUM. I don't see how using
> positional args would make that harder.

Named args make that easier in two ways: First, only extensions using the
to-be-removed option will fail. Second, removal of options reliably generates
errors, rather than bogusly use one field for another, just because the types
are compatible.

Greetings,

Andres Freund

  25. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-26T10:29:42Z

    On 25.01.26 18:52, Jelte Fennema-Nio wrote:
> On Sun Jan 25, 2026 at 5:50 PM CET, Andres Freund wrote:
>> I'm pretty sceptical this is the right direction. 
> 
> The only other option I can think of is not supporting C++ extension on
> MSVC unless they are compiled with C++20 (or later). I don't
> particularly care about Windows C++ extensions myself, so I personally
> would be fine with that choice. It seems a bit harsh, though.

Maybe it would be enough to only support PG_MODULE_MAGIC (without 
arguments) in C++ for now.

That would still require removing the named initializers inside 
PG_MODULE_MAGIC_DATA(), but that's only an internal change, and it would 
not affect C-language users of PG_MODULE_MAGIC_EXT, and we wouldn't lock 
ourselves into a particular style in C++.

Then, maybe in a couple of years, when C++20 is more widely available, 
we could enable PG_MODULE_MAGIC_EXT for C++, or design an alternative 
construct for C++.

  26. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-26T10:43:54Z

    On Mon, 26 Jan 2026 at 11:29, Peter Eisentraut <peter@eisentraut.org> wrote:
> Maybe it would be enough to only support PG_MODULE_MAGIC (without
> arguments) in C++ for now.

You mean by explicitly ifdefing out PG_MODULE_MAGIC_EXT to make it
unusable in C++? Or just not adding the additional documentation that
I added in my patch?
I'm currently using PG_MODULE_MAGIC_EXT in the C++ extension that I
maintain, and I'd prefer to continue doing so. Especially because it
(currently) doesn't have to work on MSVC for my purposes.

  27. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-01-26T10:47:24Z

    On Sun, 25 Jan 2026 at 21:06, Andres Freund <andres@anarazel.de> wrote:
> Named args make that easier in two ways: First, only extensions using the
> to-be-removed option will fail. Second, removal of options reliably generates
> errors, rather than bogusly use one field for another, just because the types
> are compatible.

Fair enough, for removals it has some benefits. Still seems like a
relatively small win for something I don't expect us to be doing
anytime soon (name and version I expect to stay around forever).

  28. Re: Make copyObject work in C++

    Bryan Green <dbryan.green@gmail.com> — 2026-02-04T15:54:37Z

    On 1/25/2026 6:42 AM, Jelte Fennema-Nio wrote:
> On Tue Jan 20, 2026 at 5:28 PM CET, Peter Eisentraut wrote:
>> I have split your first patch further.  For a start, I left out the
>> PG_MODULE_MAGIC*-related changes and disabled the module under MSVC.
>> This has been committed.  I plan to let the buildfarm run with it for
>> a day or two and then add in the basic MSVC support.
> 
> To hopefully make your life a bit easier. Here's a rebased version that
> enables the MSVC support again, with an updated commit message.
> 
This causes the build to break on VS 2022.  Versions prior do not have
support for __typeof_unqual__.  This would have led to
HAVE_TYPEOF_UNQUAL being not defined on the buildfarm causing the
fallback to copyObjectImpl() for VS 2019.

When you build on VS 2022 you will get an error:
../src/backend/commands/event_trigger.c(1901): error C2100: you cannot
dereference an operand of type 'void'

VS 2022 (MSVC) does not handle the void * dereference the way gcc/clang
does (thanks to GNU extensions, I believe).  It exposes
__typeof_unqual__ even it C11, but enforces strict C semantics on the
void * dereference.  To work on this platform the call
copyObject(lfirst(cell)) would need to have a cast to the correct
concrete type: copyObject((Node *)lfirst(cell)).

I was about to update to VS 2026, but now I think I should have an
instance of VS from 2019, 2022, and 2026.

-- 
Bryan Green
EDB: https://www.enterprisedb.com

  29. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-07T09:33:43Z

    On 04.02.26 16:54, Bryan Green wrote:
> On 1/25/2026 6:42 AM, Jelte Fennema-Nio wrote:
>> On Tue Jan 20, 2026 at 5:28 PM CET, Peter Eisentraut wrote:
>>> I have split your first patch further.  For a start, I left out the
>>> PG_MODULE_MAGIC*-related changes and disabled the module under MSVC.
>>> This has been committed.  I plan to let the buildfarm run with it for
>>> a day or two and then add in the basic MSVC support.
>>
>> To hopefully make your life a bit easier. Here's a rebased version that
>> enables the MSVC support again, with an updated commit message.
>>
> This causes the build to break on VS 2022.  Versions prior do not have
> support for __typeof_unqual__.  This would have led to
> HAVE_TYPEOF_UNQUAL being not defined on the buildfarm causing the
> fallback to copyObjectImpl() for VS 2019.
> 
> When you build on VS 2022 you will get an error:
> ../src/backend/commands/event_trigger.c(1901): error C2100: you cannot
> dereference an operand of type 'void'
> 
> VS 2022 (MSVC) does not handle the void * dereference the way gcc/clang
> does (thanks to GNU extensions, I believe).  It exposes
> __typeof_unqual__ even it C11, but enforces strict C semantics on the
> void * dereference.  To work on this platform the call
> copyObject(lfirst(cell)) would need to have a cast to the correct
> concrete type: copyObject((Node *)lfirst(cell)).
> 
> I was about to update to VS 2026, but now I think I should have an
> instance of VS from 2019, 2022, and 2026.

I have reverted this patch for now to research it further.

  30. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-02-13T10:28:20Z

    On Sun Jan 25, 2026 at 9:06 PM CET, Andres Freund wrote:
> Named args make that easier in two ways: First, only extensions using the
> to-be-removed option will fail. Second, removal of options reliably generates
> errors, rather than bogusly use one field for another, just because the types
> are compatible.

After discussing the topic in-person with Peter at FOSDEM. We agreed
that the best road forward was to not bother with MSVC for now. No-one
has actually expressed an interest in being able to build C++ extension
using MSVC, and the effort to support it is both non-trivial and not
without downsides to the rest of the codebase. We can always come back
to this later, possibly requiring C++20 on MSVC.

So I've removed that patch and now this patchset its goal is to improve
compatibiltity with the C++ flavor of GCC and Clang.

Patch 1 and 2 add some more macro calls to our test C++ extension. These
macros already work in GCC and Clang, this is purely to test for future
regressinos.

Patch 3 makes copyObject work when using GCC or Clang with -std=c++11 by
introducing pg_exprtype.

Patch 4 starts using pg_exprtype in more places.

I'm also working on some patches to support
StaticAssertVariableIsOfType, but I've run into some ICE compiler errors
of MSVC 2019.

  31. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-17T09:24:42Z

    On 13.02.26 11:28, Jelte Fennema-Nio wrote:
> On Sun Jan 25, 2026 at 9:06 PM CET, Andres Freund wrote:
>> Named args make that easier in two ways: First, only extensions using the
>> to-be-removed option will fail. Second, removal of options reliably 
>> generates
>> errors, rather than bogusly use one field for another, just because 
>> the types
>> are compatible.
> 
> After discussing the topic in-person with Peter at FOSDEM. We agreed
> that the best road forward was to not bother with MSVC for now. No-one
> has actually expressed an interest in being able to build C++ extension
> using MSVC, and the effort to support it is both non-trivial and not
> without downsides to the rest of the codebase. We can always come back
> to this later, possibly requiring C++20 on MSVC.
> 
> So I've removed that patch and now this patchset its goal is to improve
> compatibiltity with the C++ flavor of GCC and Clang.
> 
> Patch 1 and 2 add some more macro calls to our test C++ extension. These
> macros already work in GCC and Clang, this is purely to test for future
> regressinos.

I have committed these two.  I'll give them some time on the buildfarm 
and then look at the rest.

  32. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-19T08:31:45Z

    On 13.02.26 11:28, Jelte Fennema-Nio wrote:
> Patch 3 makes copyObject work when using GCC or Clang with -std=c++11 by
> introducing pg_exprtype.
> 
> Patch 4 starts using pg_exprtype in more places.

I found this paper

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm

which led to the addition of typeof into the C standard.

It contains a section 'Why not "decltype"?' that explains how decltype 
is different, but it also explains that if typeof were added to C++, 
then it would be

     std::remove_reference_t<decltype(T)>

What I suggest we should do here is:

1. Add a configure test that checks if the C++ compiler supports typeof.

2. If not, #define typeof to the above expression.

Then code can continue to use typeof unchanged.

  33. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-02-20T09:47:40Z

    On Thu Feb 19, 2026 at 9:31 AM CET, Peter Eisentraut wrote:
> What I suggest we should do here is:
>
> 1. Add a configure test that checks if the C++ compiler supports typeof.
>
> 2. If not, #define typeof to the above expression.
>
> Then code can continue to use typeof unchanged.

Makes total sense, I didn't realise decltype and typeof were not quite
the same thing. Attached is an updated patchset that does that.

It also includes a patch that improves unconstify and unvolatize by
using StaticAssertVariableIsOfTypeMacro instead of a custom version of
that assertion. (Like I said, in a future patch I intend to make
StaticAssertVariableIsOfTypeMacro work in C++ as well, but this seemed
like a good improvement anyway)

  34. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-02-27T16:40:21Z

    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.

  35. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-27T16:52:46Z

    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.

Have you tested whether/how these configure/meson tests work if no C++ 
compiler is found?

(I haven't, I'm just wondering.)

  36. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-02-28T11:31:24Z

    On Fri, 27 Feb 2026 at 17:52, Peter Eisentraut <peter@eisentraut.org> wrote:
> Have you tested whether/how these configure/meson tests work if no C++
> compiler is found?
>
> (I haven't, I'm just wondering.)

I hadn't before, but done now. It compiles postgres without problems
(but without the cplusplusext extension ofcourse). For meson the new
meson checks are inside have_cxx, so they are not run at all. For
configure the checks are run, but they detect typeof as not available
in C++ (because its unable to compile the test program).

  37. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-02T10:56:34Z

    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.

  38. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-06T09:23:11Z

    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.

  39. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-09T08:39:38Z

    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.

  40. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-13T09:08:08Z

    On Mon, 9 Mar 2026 at 09:39, Peter Eisentraut <peter@eisentraut.org> wrote:
> 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.

I initially intended to do this, but sadly using _Generic inside our
static assert constructs (even the new version you added) causes
internal compiler errors on MSVC 19... I agree with your other
feedback, and I think it's probably best to retract this patch (I've
marked it as committeed in the commitfest now, because of all the
other patches). The main reason I cared about this was to have a
_Generic based macro for type comparisons, which I could use in other
patches. I'll just create some there instead.

  41. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-23T09:27:51Z

    On 13.02.26 11:28, Jelte Fennema-Nio wrote:
> After discussing the topic in-person with Peter at FOSDEM. We agreed
> that the best road forward was to not bother with MSVC for now. No-one
> has actually expressed an interest in being able to build C++ extension
> using MSVC, and the effort to support it is both non-trivial and not
> without downsides to the rest of the codebase. We can always come back
> to this later, possibly requiring C++20 on MSVC.

I checked what would currently be missing to get MSVC supported. 
Attached is the patch.

I think we should commit the pg_list.h changes, since the C-style 
compound literals are not a C++ feature at all, and so without this MSVC 
would never get supported.  (Or you couldn't use PostgreSQL lists, which 
would be very limiting.)

Here is a Compiler Explorer link that I used to check that the generated 
code doesn't change: https://godbolt.org/z/ovKKzEfs6

The other changes deal with designated initializers and flexible array 
members.  These are not a blocker, since extension authors could deal 
with them themselves by adding appropriate compiler options or similar.

  42. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-23T09:58:34Z

    On Mon, 23 Mar 2026 at 10:27, Peter Eisentraut <peter@eisentraut.org> wrote:
> I think we should commit the pg_list.h changes, since the C-style
> compound literals are not a C++ feature at all, and so without this MSVC
> would never get supported.  (Or you couldn't use PostgreSQL lists, which
> would be very limiting.)

Sounds good to me.

> The other changes deal with designated initializers and flexible array
> members.  These are not a blocker, since extension authors could deal
> with them themselves by adding appropriate compiler options or similar.

I think we should add these flags to CXXFLAGS for MSVC by default,
similar to how we add -std=gnu++11/-std=c++11 for other compilers. We
can then document on the C++ extension docs page, that MSVC compilers
require C++20 support.

  43. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-27T11:23:24Z

    On 23.03.26 10:58, Jelte Fennema-Nio wrote:
> On Mon, 23 Mar 2026 at 10:27, Peter Eisentraut <peter@eisentraut.org> wrote:
>> I think we should commit the pg_list.h changes, since the C-style
>> compound literals are not a C++ feature at all, and so without this MSVC
>> would never get supported.  (Or you couldn't use PostgreSQL lists, which
>> would be very limiting.)
> 
> Sounds good to me.

This has been committed.

>> The other changes deal with designated initializers and flexible array
>> members.  These are not a blocker, since extension authors could deal
>> with them themselves by adding appropriate compiler options or similar.
> 
> I think we should add these flags to CXXFLAGS for MSVC by default,
> similar to how we add -std=gnu++11/-std=c++11 for other compilers. We
> can then document on the C++ extension docs page, that MSVC compilers
> require C++20 support.

Here is another tidied up patch set for this.  I didn't go quite as far 
as enabling C++20 by default in meson.build, this would just take more 
time to work out and test all the different combinations, but I added 
the flag to the Cirrus CI task, since there we know what compiler we have.

  44. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-29T22:53:48Z

    On Fri, 27 Mar 2026 at 12:23, Peter Eisentraut <peter@eisentraut.org> wrote:
> Here is another tidied up patch set for this.  I didn't go quite as far
> as enabling C++20 by default in meson.build, this would just take more
> time to work out and test all the different combinations, but I added
> the flag to the Cirrus CI task, since there we know what compiler we have.

I think 0001 and 0002 are good.

0003 seems awkward though. Attached is an approach that I think is
better: It actually checks for the required featureset and adds the
necessary flags to the compiler.

I also added a small patch in 0004 to align configure and meson
behaviour when no sufficiently modern compiler is found.

  45. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-31T08:33:36Z

    On 30.03.26 00:53, Jelte Fennema-Nio wrote:
> On Fri, 27 Mar 2026 at 12:23, Peter Eisentraut <peter@eisentraut.org> 
> wrote:
>> Here is another tidied up patch set for this.  I didn't go quite as far
>> as enabling C++20 by default in meson.build, this would just take more
>> time to work out and test all the different combinations, but I added
>> the flag to the Cirrus CI task, since there we know what compiler we 
>> have.
> 
> I think 0001 and 0002 are good.
> 
> 0003 seems awkward though. Attached is an approach that I think is
> better: It actually checks for the required featureset and adds the
> necessary flags to the compiler.

Hmm, note that C++ is also used for LLVM/JIT, and by requiring this 
additional feature set we are also imposing new requirements for those 
users.  This has not been fully explored, and I hesitate to add such a 
new requirement at the last moment.

But how about this: We add the feature test that you propose and enable 
the extension based on that.  See attached patch.  This reduces to 
essentially a three-line patch, much simpler than all previous proposals.

  46. Re: Make copyObject work in C++

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-31T09:09:59Z

    On Tue, 31 Mar 2026 at 10:33, Peter Eisentraut <peter@eisentraut.org> wrote:
> Hmm, note that C++ is also used for LLVM/JIT, and by requiring this
> additional feature set we are also imposing new requirements for those
> users.  This has not been fully explored, and I hesitate to add such a
> new requirement at the last moment.

I understand the hesitation, but in practice we already impose those
requirements anyway for non-MSVC compilers because test_cplusplusext
doesn't compile without it. So any compiler that would cause problems
with the new featureset would have already complained about that
before.

> But how about this: We add the feature test that you propose and enable
> the extension based on that.  See attached patch.  This reduces to
> essentially a three-line patch, much simpler than all previous proposals.

If you're still worried, then this sounds like a fine middle-ground
for now. I think we should reconsider adding the automatic /std:c++20
flag for the PG20 dev cycle though.

  47. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-01T05:54:07Z

    On 31.03.26 11:09, Jelte Fennema-Nio wrote:
> On Tue, 31 Mar 2026 at 10:33, Peter Eisentraut <peter@eisentraut.org> wrote:
>> Hmm, note that C++ is also used for LLVM/JIT, and by requiring this
>> additional feature set we are also imposing new requirements for those
>> users.  This has not been fully explored, and I hesitate to add such a
>> new requirement at the last moment.
> 
> I understand the hesitation, but in practice we already impose those
> requirements anyway for non-MSVC compilers because test_cplusplusext
> doesn't compile without it. So any compiler that would cause problems
> with the new featureset would have already complained about that
> before.
> 
>> But how about this: We add the feature test that you propose and enable
>> the extension based on that.  See attached patch.  This reduces to
>> essentially a three-line patch, much simpler than all previous proposals.
> 
> If you're still worried, then this sounds like a fine middle-ground
> for now. I think we should reconsider adding the automatic /std:c++20
> flag for the PG20 dev cycle though.

Ok, I have committed the shown patch.

  48. Re: Make copyObject work in C++

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-09T11:41:39Z

    Hi,

On Wed, Apr 01, 2026 at 07:54:07AM +0200, Peter Eisentraut wrote:
> On 31.03.26 11:09, Jelte Fennema-Nio wrote:
> > On Tue, 31 Mar 2026 at 10:33, Peter Eisentraut <peter@eisentraut.org> wrote:
> > > Hmm, note that C++ is also used for LLVM/JIT, and by requiring this
> > > additional feature set we are also imposing new requirements for those
> > > users.  This has not been fully explored, and I hesitate to add such a
> > > new requirement at the last moment.
> > 
> > I understand the hesitation, but in practice we already impose those
> > requirements anyway for non-MSVC compilers because test_cplusplusext
> > doesn't compile without it. So any compiler that would cause problems
> > with the new featureset would have already complained about that
> > before.
> > 
> > > But how about this: We add the feature test that you propose and enable
> > > the extension based on that.  See attached patch.  This reduces to
> > > essentially a three-line patch, much simpler than all previous proposals.
> > 
> > If you're still worried, then this sounds like a fine middle-ground
> > for now. I think we should reconsider adding the automatic /std:c++20
> > flag for the PG20 dev cycle though.
> 
> Ok, I have committed the shown patch.

d50c86e74375 added a comment mentionning that StaticAssertStmt is deprecated, so
we really need the one added in test_cplusplusext.cpp?

Regards,

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

  49. Re: Make copyObject work in C++

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-14T13:10:12Z

    Hi,

On Thu, Apr 09, 2026 at 11:41:39AM +0000, Bertrand Drouvot wrote:
> Hi,
> 
> On Wed, Apr 01, 2026 at 07:54:07AM +0200, Peter Eisentraut wrote:
> > 
> > Ok, I have committed the shown patch.
> 
> d50c86e74375 added a comment mentionning that StaticAssertStmt is deprecated, so
> we really need the one added in test_cplusplusext.cpp?

Now that 66ad764c8d5 is in, the only remaining use of StaticAssertStmt() is in
test_cplusplusext.cpp. What about the attached to get rid of it? 

Regards,

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

  50. Re: Make copyObject work in C++

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-16T08:07:35Z

    On 14.04.26 15:10, Bertrand Drouvot wrote:
> Hi,
> 
> On Thu, Apr 09, 2026 at 11:41:39AM +0000, Bertrand Drouvot wrote:
>> Hi,
>>
>> On Wed, Apr 01, 2026 at 07:54:07AM +0200, Peter Eisentraut wrote:
>>>
>>> Ok, I have committed the shown patch.
>>
>> d50c86e74375 added a comment mentionning that StaticAssertStmt is deprecated, so
>> we really need the one added in test_cplusplusext.cpp?
> 
> Now that 66ad764c8d5 is in, the only remaining use of StaticAssertStmt() is in
> test_cplusplusext.cpp. What about the attached to get rid of it?

This is a test module.  Even if the construct is deprecated, we can 
still test it.

  51. Re: Make copyObject work in C++

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-16T11:31:27Z

    Hi,

On Thu, Apr 16, 2026 at 10:07:35AM +0200, Peter Eisentraut wrote:
> On 14.04.26 15:10, Bertrand Drouvot wrote:
> > Hi,
> > 
> > On Thu, Apr 09, 2026 at 11:41:39AM +0000, Bertrand Drouvot wrote:
> > > Hi,
> > > 
> > > On Wed, Apr 01, 2026 at 07:54:07AM +0200, Peter Eisentraut wrote:
> > > > 
> > > > Ok, I have committed the shown patch.
> > > 
> > > d50c86e74375 added a comment mentionning that StaticAssertStmt is deprecated, so
> > > we really need the one added in test_cplusplusext.cpp?
> > 
> > Now that 66ad764c8d5 is in, the only remaining use of StaticAssertStmt() is in
> > test_cplusplusext.cpp. What about the attached to get rid of it?
> 
> This is a test module.  Even if the construct is deprecated, we can still
> test it.

Right, but I was thinking that if we introduce a "pg_attribute_deprecated" macro
(like discussed in [1] and [2]) and make use of it for StaticAssertStmt(), then
this test module would generate Warnings.

We can still come back to it should the above be implemented.

[1]: https://postgr.es/m/CA%2BhUKGK2zuRevnNzCpVzLA7ieHnJoYPnDvgtWRcB4pVnOzchhQ%40mail.gmail.com
[2]: https://postgr.es/m/aRGa87Ab0f3ItWRV@ip-10-97-1-34.eu-west-3.compute.internal

Regards,

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