Re: Make copyObject work in C++

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Make copyObject work in C++
Date: 2026-03-09 08:39:38
Message-ID: 9770b32b-84d4-4a36-9ff6-8fb54144cd24@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-03-09 08:44:45 Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
Previous Message jian he 2026-03-09 08:15:42 Re: Refactor handling of "-only" options in pg_dump, pg_restore