Re: Change copyObject() to use typeof_unqual - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Change copyObject() to use typeof_unqual
Date
Msg-id ff129805-1516-478a-a438-145880165c58@eisentraut.org
Whole thread Raw
In response to Re: Change copyObject() to use typeof_unqual  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: Change copyObject() to use typeof_unqual
Re: Change copyObject() to use typeof_unqual
List pgsql-hackers
On 07.03.26 01:17, Jelte Fennema-Nio wrote:
> On Fri, 6 Mar 2026 at 20:17, Peter Eisentraut <peter@eisentraut.org> wrote:
>> This revealed an insufficiency in that commit, which I fix in the first
>> patch.
> 
> Thanks!

There is a failure related to this on buildfarm member sevengill:

../pgsql/src/test/modules/test_cplusplusext/test_cplusplusext.cpp:41:22: 
error: no template named 'remove_reference_t' in namespace 'std'; did 
you mean 'remove_reference'?

I don't know how that makes sense.  Maybe this is a problem in the local 
installation of the compiler or standard library.

(This is also a bit suspicious because AFAICT, clang 15 defaults to 
C++14, but on that animal it thinks it needs to add -std=gnu++11.)

>> I have addressed the above problem by swapping the order of the probes
>> (putting the underscore variant first), as discussed.
> 
> Annoying that this is needed, but I agree that it's the least bad
> option in this case.

I committed this and it still fails, but the failure is now narrower. 
There is a failure on buildfarm member taipan because it uses an unusual 
combination of gcc and clang (the gcc is much newer than clang).  The 
only sensible workaround I could think of is a hardcoded override based 
on the clang version, as in the attached patch.  And alternative is that 
we decide that we don't want to support this combination, meaning that 
we would effectively require that clang is approximately as-old-or-newer 
than gcc.

Attachment

pgsql-hackers by date:

Previous
From: "Greg Burd"
Date:
Subject: Re: Areas for Solaris support modernization
Next
From: Bertrand Drouvot
Date:
Subject: Re: Tighten asserts on ParallelWorkerNumber a little bit