Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=Flowed
Date: Sun, 25 Jan 2026 18:52:37 +0100
Message-Id: <DFXV193BOBQ8.1BY2PK8YRJ9O1@jeltef.nl>
Cc: "Peter Eisentraut" <peter@eisentraut.org>, "PostgreSQL Hackers"
 <pgsql-hackers@lists.postgresql.org>, "Thomas Munro"
 <thomas.munro@gmail.com>
Subject: Re: Make copyObject work in C++
To: "Andres Freund" <andres@anarazel.de>
From: "Jelte Fennema-Nio" <postgres@jeltef.nl>
References: <CAGECzQR21OnnKiZO_1rLWO0-16kg1JBxnVq-wymYW0-_1cUNtg@mail.gmail.com> <4d8b9e53-3f37-43f0-a4aa-5bda9c7961b3@eisentraut.org> <DFEUMBSUG8KA.XGY0CN9PFPR2@jeltef.nl> <DFKV26A4CHG2.CB7NJ1X62BKH@jeltef.nl> <fd1a4790-4fbc-43b4-a385-e3b98b9ed04d@eisentraut.org> <DFQYWIJD4L1J.3HQFOWSWKLFOR@jeltef.nl> <4e82f77b-acad-4356-94f6-8255135fb36b@eisentraut.org> <DFXOG2P1QMS8.3L7MCAL0E6MVJ@jeltef.nl> <ztktlrqatfj4roqhdjurccb3b4mf5hrycybfrzwupt4xmbwjt4@alrtyxhz5sns>
In-Reply-To: <ztktlrqatfj4roqhdjurccb3b4mf5hrycybfrzwupt4xmbwjt4@alrtyxhz5sns>
Archived-At: <https://www.postgresql.org/message-id/DFXV193BOBQ8.1BY2PK8YRJ9O1%40jeltef.nl>
Precedence: bulk

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

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 add=
ed
> 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 designa=
ted
> and non-designated initializers that I can see? If you use
> PG_MODULE_MAGIC_EXT(.name =3D "whatnot"), it evaluates down to
>
> extern __attribute__((visibility("default"))) const Pg_magic_struct *Pg_m=
agic_func(void); const Pg_magic_struct * Pg_magic_func(void) { static const=
 Pg_magic_struct Pg_magic_data =3D { .len =3D sizeof(Pg_magic_struct), .abi=
_fields =3D { 190000 / 100, 100, 32, 64, true, "PostgreSQL", }, .name=3D"wh=
atnot"}; return &Pg_magic_data; } extern int no_such_variable;
>
> And indeed, contra to what you reported upthread, I can't get clang to re=
port
> 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=3D'-fno-omit-frame-pointer' -Dcassert=3Dtrue
meson test -C build --suite setup --suite test_cplusplusext

[2202/2268] Compiling C++ object src/test/modules/test_cplusplusext/test_cp=
lusplusext.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 initiali=
zer list is a C99 extension [-Wc99-designator]
   23 | PG_MODULE_MAGIC_EXT(.name=3D"test_cplusplusext",.version=3D "1.2");
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~
../src/include/fmgr.h:548:24: note: expanded from macro 'PG_MODULE_MAGIC_EX=
T'
  548 |                 PG_MODULE_MAGIC_DATA(__VA_ARGS__); \
      |                                      ^~~~~~~~~~~
../src/include/fmgr.h:509:2: note: expanded from macro 'PG_MODULE_MAGIC_DAT=
A'
  509 |         __VA_ARGS__ \
      |         ^~~~~~~~~~~
../src/test/modules/test_cplusplusext/test_cplusplusext.cpp:23:1: note: fir=
st non-designated initializer is here
   23 | PG_MODULE_MAGIC_EXT(.name=3D"test_cplusplusext",.version=3D "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_DAT=
A'
  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=3D"test_cplusplusext",.version=3D "1.2");


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