Re: Make copyObject work in C++

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