Обсуждение: Change copyObject() to use typeof_unqual

Currently, when the argument of copyObject() is const-qualified, the 
return type is also, because the use of typeof carries over all the 
qualifiers.  This is incorrect, since the point of copyObject() is to 
  make a copy to mutate.  But apparently no code ran into it.

The new implementation uses typeof_unqual, which drops the qualifiers, 
making this work correctly.

typeof_unqual is standardized in C23, but all recent versions of all the 
usual compilers support it even in non-C23 mode, at least as 
__typeof_unqual__.  We add a configure/meson test for typeof_unqual and 
__typeof_unqual__ and use it if it's available, else we use the existing 
fallback of just returning void *.

(Even MSVC supports it, if we use a slightly newer version than is on 
CI.  For example, the new buildfarm member unicorn would support it.)

The second patch make some changes to take advantage of this improved 
qualifier handling.  EventTriggerCollectSimpleCommand() is a good 
example:  It takes a node tree and makes a copy that it keeps around for 
its internal purposes, but it can't communicate via its function 
signature that it promises not scribble on the passed node tree.  That 
is now fixed.

The obvious drawback is that if you use an older compiler that supports 
typeof but not typeof_unqual, this change will make you lose that check. 
  Currently, on the Cirrus CI system, only the NetBSD and OpenBSD tasks 
are affected by this.

Anyway, the reason I'm posting this now instead of, say, waiting another 
year, is that over in the thread "Make copyObject work in C++"[0], we're 
discussing, well, making copyObject() work in (standard) C++ (typeof and 
typeof_unqual are not in C++).  Assuming we want to make the 
typeof_unqual change in principle, I figured it would be worth 
considering doing that change first and then developing a C++ equivalent 
of that, instead of making a C++ equivalent of the current logic and 
then having to find another C++ solution when changing to typeof_unqual.


[0]: 
https://www.postgresql.org/message-id/flat/CAGECzQR21OnnKiZO_1rLWO0-16kg1JBxnVq-wymYW0-_1cUNtg@mail.gmail.com

Hi Peter!

On 20.01.2026 10:37, Peter Eisentraut wrote:
> Currently, when the argument of copyObject() is const-qualified, the
> return type is also, because the use of typeof carries over all the
> qualifiers.  This is incorrect, since the point of copyObject() is to
>  make a copy to mutate.  But apparently no code ran into it.

Great change. I've ran into that multiple times and had to
un-const-correct my code because of how copyObject() works.

> The new implementation uses typeof_unqual, which drops the qualifiers,
> making this work correctly.
> 
> typeof_unqual is standardized in C23, but all recent versions of all the
> usual compilers support it even in non-C23 mode, at least as
> __typeof_unqual__.  We add a configure/meson test for typeof_unqual and
> __typeof_unqual__ and use it if it's available, else we use the existing
> fallback of just returning void *.
> 
> (Even MSVC supports it, if we use a slightly newer version than is on
> CI.  For example, the new buildfarm member unicorn would support it.)

I'm not too familiar with the build system, so I let someone else review
this part.

> The second patch make some changes to take advantage of this improved
> qualifier handling.  EventTriggerCollectSimpleCommand() is a good
> example:  It takes a node tree and makes a copy that it keeps around for
> its internal purposes, but it can't communicate via its function
> signature that it promises not scribble on the passed node tree.  That
> is now fixed.

The changes to EvenTriggerCollectSimpleCommand() look good to me.

Are you planning to look at the rest of the code as well? At a quick
glance there seem to be more places that can be changed in similar ways,
e.g. see refresh_matview_datafill().

--
David Geier

Hi,

On 2026-01-20 10:37:35 +0100, Peter Eisentraut wrote:
> (Even MSVC supports it, if we use a slightly newer version than is on CI.
> For example, the new buildfarm member unicorn would support it.)

FWIW, we've recently installed a newer msvc version in the image, we could
switch to that if desired.

Greetings,

Andres

On 20.01.26 11:48, David Geier wrote:
> Are you planning to look at the rest of the code as well? At a quick
> glance there seem to be more places that can be changed in similar ways,
> e.g. see refresh_matview_datafill().

I did as much looking as I was planning for this.  If you find more 
things to improve, please go ahead.

On 20.01.26 10:37, Peter Eisentraut wrote:
> Currently, when the argument of copyObject() is const-qualified, the 
> return type is also, because the use of typeof carries over all the 
> qualifiers.  This is incorrect, since the point of copyObject() is to 
>   make a copy to mutate.  But apparently no code ran into it.
> 
> The new implementation uses typeof_unqual, which drops the qualifiers, 
> making this work correctly.
> 
> typeof_unqual is standardized in C23, but all recent versions of all the 
> usual compilers support it even in non-C23 mode, at least as 
> __typeof_unqual__.  We add a configure/meson test for typeof_unqual and 
> __typeof_unqual__ and use it if it's available, else we use the existing 
> fallback of just returning void *.

I committed this first part, but it ran into some trouble on the buildfarm:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=taipan&dt=2026-02-04%2008%3A39%3A34

The problem is that configure detected that gcc supports typeof_unqual, 
but the clang used to produce the .bc files does not.

This seems to be a possible problem in general, if we do all these 
configure checks with $CC, but then run $CLANG assuming all the results 
hold.

My first attempt to fix this was to set CLANG='clang -std=gnu23' to 
effectively put clang into approximately the same mode as gcc.  This 
fixes this particular issue but then later fails when compiling .bc 
files for the test_cplusplus module:

clang -std=gnu23 -xc++ -Wno-ignored-attributes -O2  -I. -I. 
-I../../../../src/include -D_GNU_SOURCE  -I/usr/include/libxml2 
-flto=thin -emit-llvm -c -o test_cplusplusext.bc test_cplusplusext.cpp
error: invalid argument '-std=gnu23' not allowed with 'C++'

This might be another looming problem.  Do we need to look up, say, 
CLANGXX separately from CLANG?

Another attempt was to switch the order of the configure test to check 
for __typeof_unqual__ before typeof_unqual.  This works, but it seems 
totally unprincipled.

Any thoughts?

(Btw., the buildfarm member description says gcc 13, but it's actually 
using gcc 15.)

Peter Eisentraut <peter@eisentraut.org> writes:
> Another attempt was to switch the order of the configure test to check 
> for __typeof_unqual__ before typeof_unqual.  This works, but it seems 
> totally unprincipled.

Seems perfectly reasonable from here.

            regards, tom lane

On 04.02.26 11:46, Peter Eisentraut wrote:
> On 20.01.26 10:37, Peter Eisentraut wrote:
>> Currently, when the argument of copyObject() is const-qualified, the 
>> return type is also, because the use of typeof carries over all the 
>> qualifiers.  This is incorrect, since the point of copyObject() is to 
>>   make a copy to mutate.  But apparently no code ran into it.
>>
>> The new implementation uses typeof_unqual, which drops the qualifiers, 
>> making this work correctly.
>>
>> typeof_unqual is standardized in C23, but all recent versions of all 
>> the usual compilers support it even in non-C23 mode, at least as 
>> __typeof_unqual__.  We add a configure/meson test for typeof_unqual 
>> and __typeof_unqual__ and use it if it's available, else we use the 
>> existing fallback of just returning void *.
> 
> I committed this first part, but it ran into some trouble on the buildfarm:
> 
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl? 
> nm=taipan&dt=2026-02-04%2008%3A39%3A34
> 
> The problem is that configure detected that gcc supports typeof_unqual, 
> but the clang used to produce the .bc files does not.

Here is a new version, after the previous one was reverted.

This is rebased over commit 1887d822f14 and now also provides a C++ 
implementation, corresponding to the C++ typeof implementation added by 
that commit.

This revealed an insufficiency in that commit, which I fix in the first 
patch.

I have addressed the above problem by swapping the order of the probes 
(putting the underscore variant first), as discussed.

There was also an issue that newer MSVC versions claimed to support 
typeof_unqual but it didn't work correctly.  I have enhanced the 
configure probes to detect this problem.

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!

> 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.

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.

> On 13 Mar 2026, at 11:43, Peter Eisentraut <peter@eisentraut.org> wrote:

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

I ran into this as well on clang 15 via XCode with no gcc involved:

../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'? 
        RangeTblRef *copy = copyObject(nodec);
                            ^~~~~~~~~~~~~~~~~
--
Daniel Gustafsson

On 13.03.26 14:03, Daniel Gustafsson wrote:
>> On 13 Mar 2026, at 11:43, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
>> I committed this and it still fails, but the failure is now narrower. There is a failure on buildfarm member taipan
becauseit uses an unusual combination of gcc and clang (the gcc is much newer than clang).  The only sensible
workaroundI could think of is a hardcoded override based on the clang version, as in the attached patch.  And
alternativeis that we decide that we don't want to support this combination, meaning that we would effectively require
thatclang is approximately as-old-or-newer than gcc.
 
> 
> I ran into this as well on clang 15 via XCode with no gcc involved:
> 
> ../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'?
 
>          RangeTblRef *copy = copyObject(nodec);
>                              ^~~~~~~~~~~~~~~~~

Jelte,

I read here

https://en.cppreference.com/w/cpp/types/remove_reference.html

that remove_reference_t is actually in C++14, which might explain this 
failure, if the compiler is in C++11 mode.

I don't understand the difference between remove_reference and 
remove_reference_t.

On Fri, 13 Mar 2026 at 17:00, Peter Eisentraut <peter@eisentraut.org> wrote:
> that remove_reference_t is actually in C++14, which might explain this
> failure, if the compiler is in C++11 mode.

Yeah that's almost certainly it... Sorry about that.

> I don't understand the difference between remove_reference and
> remove_reference_t.

They are equivalent only the _t version as a bit less verbose.
Attached should fix it.

On Fri, 13 Mar 2026 at 17:15, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> Attached should fix it.

Okay corrected in this v2, which fixes all of the places I could find.

On 13.03.26 17:18, Jelte Fennema-Nio wrote:
> On Fri, 13 Mar 2026 at 17:15, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>> Attached should fix it.
> 
> Okay corrected in this v2, which fixes all of the places I could find.

This doesn't appear to work in this example program:

```
#include <type_traits>

#define mytypeof(x) std::remove_reference<decltype(x)>::value

void foo(void)
{
     int a;
     mytypeof(a) b;
}
```

Based on some internet search, it appears that ::type would work.  But 
it also appears to work without either one.

On Sat, 14 Mar 2026 at 14:03, Peter Eisentraut <peter@eisentraut.org> wrote:
> This doesn't appear to work in this example program:

Ugh, I should not send emails end of day on a friday in a rush.

Attached is fixed v3 which uses ::type instead.

I was able to reproduce the compilation errors on my machine by using
CXXFLAGS='-std=c++11' when configuring meson, and this patch fixes them.
I think it would be good if we would run one of our CI jobs in c11 and
c++11 (non-gnu) mode so we catch these kind of issues before hitting the
build farm.

On Fri, 13 Mar 2026 at 11:43, Peter Eisentraut <peter@eisentraut.org> wrote:
> 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.

If we can then start prefering typeof_unqual over __typeof_unqual__ in
the configure check for CC, then I think I like this as a workaround.

If not, then I'm starting to think that actually checking support for
this feature for CLANG is probably easier to understand (and less
fragile) than combining all of these tricks together. Attached is a
patch to do so.

This only does it for CLANG, not for CLANG compiling C++ files.
Theoretically that could be necessary, but I couldn't find a C++
compiler that supports any spelling of typeof_unqual. So I'm not even
sure we need the current CXX check for typeof_unqual, I think we could
remove that too and always use the fallback.

> 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.

Given that Tom seems to have reproduced this on Fedora 40, it sounds
like we should fix it.

"Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
> If not, then I'm starting to think that actually checking support for
> this feature for CLANG is probably easier to understand (and less
> fragile) than combining all of these tricks together. Attached is a
> patch to do so. 

+1 for concept, but don't you need to fix meson.build too?

>> 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.

> Given that Tom seems to have reproduced this on Fedora 40, it sounds
> like we should fix it.

Yeah.  Given Fedora's development cycle, it is a certainty that they
shipped gcc and clang versions no more than a couple months different
in age.  So even if we wanted to adopt the restriction Peter suggests,
there are not-very-old systems on which it fails.

            regards, tom lane

On Sun, 15 Mar 2026 at 23:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
> > If not, then I'm starting to think that actually checking support for
> > this feature for CLANG is probably easier to understand (and less
> > fragile) than combining all of these tricks together. Attached is a
> > patch to do so.
>
> +1 for concept, but don't you need to fix meson.build too?

I believe that we don't have fully working bc compilation for meson[1],
so I'm not entirely sure how to test out if it actually works. But the
attached now does *something* for meson too at least.

[1]: https://www.postgresql.org/message-id/flat/206b001d-1884-4081-bd02-bed5c92f02ba%40eisentraut.org

On 16.03.26 00:57, Jelte Fennema-Nio wrote:
> On Sun, 15 Mar 2026 at 23:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> "Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
>> > If not, then I'm starting to think that actually checking support for
>> > this feature for CLANG is probably easier to understand (and less
>> > fragile) than combining all of these tricks together. Attached is a
>> > patch to do so.
>>
>> +1 for concept, but don't you need to fix meson.build too?
> 
> I believe that we don't have fully working bc compilation for meson[1],
> so I'm not entirely sure how to test out if it actually works. But the
> attached now does *something* for meson too at least.

Yeah, this is tricky to analyze and test because the bc compilation 
doesn't even exist yet.

I'm tempted to go with my proposed patch of a version-based override for 
the time being.

On Mon, 16 Mar 2026 at 13:47, Peter Eisentraut <peter@eisentraut.org> wrote:
> I'm tempted to go with my proposed patch of a version-based override for
> the time being.

Sounds good to me. But let's not forget to swap back the order of
detection for typeof_unqual vs __typeof_unqual__. Afaict that's not
needed anymore and the comment there only becomes confusing with this
new fix.

Also, it might be nice to only do your version based override, if
we're actually compiling bitcode. In my patch I used
-DPG_COMPILING_BITCODE for that. Otherwise this override can also
happen for regular compiles using clang, which I think would be a bit
confusing.

Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> On Mon, 16 Mar 2026 at 13:47, Peter Eisentraut <peter@eisentraut.org> wrote:
>> I'm tempted to go with my proposed patch of a version-based override for
>> the time being.

> Sounds good to me.

I confirmed that Peter's
0001-Hardcode-override-of-typeof_unqual-for-clang-for-bit.patch
fixes the problem on my Fedora 40 system.  I concur it seems a
lot less messy than Jelte's patch, although I have a nasty
feeling that we'll eventually need something closer to that.

> But let's not forget to swap back the order of
> detection for typeof_unqual vs __typeof_unqual__. Afaict that's not
> needed anymore and the comment there only becomes confusing with this
> new fix.

+1

> Also, it might be nice to only do your version based override, if
> we're actually compiling bitcode. In my patch I used
> -DPG_COMPILING_BITCODE for that. Otherwise this override can also
> happen for regular compiles using clang, which I think would be a bit
> confusing.

Doesn't seem like an issue.  If we're using an old clang as CC, we
would have detected that it doesn't accept typeof_unqual anyway.
I think there is also no effect if we are using gcc as CC and
clang++ as CXX, because per upthread discussion, typeof_unqual
isn't going to work in C++ mode anyhow.

            regards, tom lane

Hi,

On Mon, Mar 16, 2026 at 8:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> > On Mon, 16 Mar 2026 at 13:47, Peter Eisentraut <peter@eisentraut.org> wrote:
> >> I'm tempted to go with my proposed patch of a version-based override for
> >> the time being.
>
> > Sounds good to me.
>
> I confirmed that Peter's
> 0001-Hardcode-override-of-typeof_unqual-for-clang-for-bit.patch
> fixes the problem on my Fedora 40 system.

I'm still encountering the following error while building from source
at commit f4af7849b3d when using autoconf:

execParallel.c:154:9: error: call to undeclared function
'typeof_unqual'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
  154 |         plan = copyObject(plan);
      |                ^
../../../src/include/nodes/nodes.h:230:27: note: expanded from macro
'copyObject'
  230 | #define copyObject(obj) ((typeof_unqual(*(obj)) *) copyObjectImpl(obj))
      |                           ^
execParallel.c:154:9: error: expected expression
../../../src/include/nodes/nodes.h:230:50: note: expanded from macro
'copyObject'
  230 | #define copyObject(obj) ((typeof_unqual(*(obj)) *) copyObjectImpl(obj))
      |                                                  ^
analyze.c:3213:27: error: call to undeclared function 'typeof_unqual';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
 3213 |                 stmt->into->viewQuery = copyObject(query);
      |                                         ^
../../../src/include/nodes/nodes.h:230:27: note: expanded from macro
'copyObject'
  230 | #define copyObject(obj) ((typeof_unqual(*(obj)) *) copyObjectImpl(obj))
      |                           ^
analyze.c:3213:27: error: expected expression
../../../src/include/nodes/nodes.h:230:50: note: expanded from macro
'copyObject'
  230 | #define copyObject(obj) ((typeof_unqual(*(obj)) *) copyObjectImpl(obj))
      |                                                  ^
2 errors generated.
:
(many similar errors)

I'm using Fedora 43 and gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7).
The issue doesn't happen when using meson+ninja.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Masahiko Sawada <sawada.mshk@gmail.com> writes:
> I'm still encountering the following error while building from source
> at commit f4af7849b3d when using autoconf:

> execParallel.c:154:9: error: call to undeclared function
> 'typeof_unqual'; ISO C99 and later do not support implicit function
> declarations [-Wimplicit-function-declaration]
>   154 |         plan = copyObject(plan);
>       |                ^

> I'm using Fedora 43 and gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7).

Ugh, yeah, reproduced here.  FTR, this platform has

$ gcc --version
gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7)
$ clang --version
clang version 21.1.8 (Fedora 21.1.8-4.fc43)

While this version of clang doesn't like typeof_unqual, it does take
__typeof_unqual__.  So maybe we were premature to decide that we
could prefer the typeof_unqual spelling.  I can get it to build
if I use __typeof_unqual__.

> The issue doesn't happen when using meson+ninja.

Per upthread, we don't have bitcode compilation working in the
meson buildsystem, so we aren't trying to invoke clang in that
case.

            regards, tom lane

I wrote:
> $ clang --version
> clang version 21.1.8 (Fedora 21.1.8-4.fc43)

> While this version of clang doesn't like typeof_unqual, it does take
> __typeof_unqual__.  So maybe we were premature to decide that we
> could prefer the typeof_unqual spelling.  I can get it to build
> if I use __typeof_unqual__.

After further experimentation: it will take typeof_unqual with
"-std=c23" ... but, again, we are not passing it that switch,
and the default is evidently some older C version.

            regards, tom lane

On Tue Mar 17, 2026 at 3:39 AM CET, Tom Lane wrote:
> While this version of clang doesn't like typeof_unqual, it does take
> __typeof_unqual__.  So maybe we were premature to decide that we
> could prefer the typeof_unqual spelling.

Hmmm, that makes sense. How about this patch to at least keep the
all the logic related to this in one place? I was able to reproduce this
error using the following flags, and this fixes the issue for me.

CC=clang-21 CXX=clang++-21 CFLAGS=-std=c23 BITCODE_CFLAGS=-std=gnu17 CLANG=clang-19 LLVM_CONFIG=llvm-config-19

"Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
> On Tue Mar 17, 2026 at 3:39 AM CET, Tom Lane wrote:
>> While this version of clang doesn't like typeof_unqual, it does take
>> __typeof_unqual__.  So maybe we were premature to decide that we
>> could prefer the typeof_unqual spelling.

> Hmmm, that makes sense. How about this patch to at least keep the
> all the logic related to this in one place? I was able to reproduce this
> error using the following flags, and this fixes the issue for me.

Seems reasonable, and I confirm that this fixes things for me on
Fedora 43.

            regards, tom lane

On 17.03.26 11:56, Jelte Fennema-Nio wrote:
> On Tue Mar 17, 2026 at 3:39 AM CET, Tom Lane wrote:
>> While this version of clang doesn't like typeof_unqual, it does take
>> __typeof_unqual__.  So maybe we were premature to decide that we
>> could prefer the typeof_unqual spelling.
> 
> Hmmm, that makes sense. How about this patch to at least keep the
> all the logic related to this in one place? I was able to reproduce this
> error using the following flags, and this fixes the issue for me.
> 
> CC=clang-21 CXX=clang++-21 CFLAGS=-std=c23 BITCODE_CFLAGS=-std=gnu17 
> CLANG=clang-19 LLVM_CONFIG=llvm-config-19

committed