public inbox for [email protected]  

help / color / mirror / Atom feed
From: Andres Freund <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Thomas Munro <[email protected]>
Subject: Re: Make copyObject work in C++
Date: Sun, 25 Jan 2026 11:50:28 -0500
Message-ID: <ztktlrqatfj4roqhdjurccb3b4mf5hrycybfrzwupt4xmbwjt4@alrtyxhz5sns> (raw)
In-Reply-To: <[email protected]>
References: <CAGECzQR21OnnKiZO_1rLWO0-16kg1JBxnVq-wymYW0-_1cUNtg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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






view thread (27+ messages)  latest in thread

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Make copyObject work in C++
  In-Reply-To: <ztktlrqatfj4roqhdjurccb3b4mf5hrycybfrzwupt4xmbwjt4@alrtyxhz5sns>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox