Feedback-ID: ie0a040ee:Fastmail
Message-ID: <9770b32b-84d4-4a36-9ff6-8fb54144cd24@eisentraut.org>
Date: Mon, 9 Mar 2026 09:39:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Make copyObject work in C++
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>
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>
 <DFXV193BOBQ8.1BY2PK8YRJ9O1@jeltef.nl>
 <2h2n2gyw2f4ucicbl3drtdkjt2wzf6b2r4wqm7xwks6vpx5j7n@imymv4hkz5jz>
 <DGDRHFD14I7Z.30DSV2XVI6V93@jeltef.nl>
 <8f8776be-6d8f-4e1c-8d21-e55052edd91b@eisentraut.org>
 <DGJP03W74JEL.3QCBCVYISLNQ6@jeltef.nl> <DGPW5WCFY7WY.1IHCDNIVVT300@jeltef.nl>
 <e54c8121-69b1-4a57-a8b4-f2b80320ac52@eisentraut.org>
 <d85c1b13-e46f-47dd-8802-7e194e8cc122@eisentraut.org>
Content-Language: en-US
In-Reply-To: <d85c1b13-e46f-47dd-8802-7e194e8cc122@eisentraut.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9770b32b-84d4-4a36-9ff6-8fb54144cd24%40eisentraut.org>
Precedence: bulk

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.