Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add some const qualifiers enabled by typeof_unqual change on copyObject

  2. Hardcode typeof_unqual to __typeof_unqual__ for clang

  3. Clean up postgres_fdw/t/010_subscription.pl.

  4. Hardcode override of typeof_unqual for clang-for-bitcode

  5. Make typeof and typeof_unqual fallback definitions work on C++11

  6. Change copyObject() to use typeof_unqual

  7. Fixes for C++ typeof implementation

  8. Support using copyObject in standard C++

  1. Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-20T09:37:35Z

    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

  2. Re: Change copyObject() to use typeof_unqual

    David Geier <geidav.pg@gmail.com> — 2026-01-20T10:48:00Z

    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

  3. Re: Change copyObject() to use typeof_unqual

    Andres Freund <andres@anarazel.de> — 2026-01-20T15:47:04Z

    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

  4. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-01-21T11:41:46Z

    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.

  5. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-04T10:46:22Z

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

  6. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-04T15:38:29Z

    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

  7. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-06T19:17:44Z

    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.

  8. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-07T00:17:42Z

    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.

  9. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-13T10:43:15Z

    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.

  10. Re: Change copyObject() to use typeof_unqual

    Daniel Gustafsson <daniel@yesql.se> — 2026-03-13T13:03:20Z

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

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

  11. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-13T16:00:15Z

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

  12. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-13T16:15:12Z

    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.

  13. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-13T16:18:18Z

    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.

  14. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-14T13:03:05Z

    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.

  15. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-14T13:41:08Z

    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.

  16. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-15T21:54:04Z

    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.

  17. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-15T22:13:30Z

    "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

  18. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-15T23:57:17Z

    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

  19. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-16T12:47:13Z

    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.

  20. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-16T13:40:52Z

    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.

  21. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-16T15:32:15Z

    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

  22. Re: Change copyObject() to use typeof_unqual

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-03-16T22:28:07Z

    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

  23. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-17T02:39:29Z

    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

  24. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-17T02:49:26Z

    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

  25. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-03-17T10:56:24Z

    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

  26. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-17T15:05:04Z

    "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

  27. Re: Change copyObject() to use typeof_unqual

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-17T15:53:28Z

    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

  28. Re: Change copyObject() to use typeof_unqual

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-06-13T12:14:02Z

    On 2026-Mar-06, Peter Eisentraut wrote:

> From f2f750f7c3ab6b73514ab2fd5f02185abe9ad59f Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter@eisentraut.org>
> Date: Fri, 6 Mar 2026 13:31:01 +0100
> Subject: [PATCH v2 1/3] Fixes for C++ typeof implementation
> 
> This fixes two bugs in commit 1887d822f14.
> 
> First, if we are using the fallback C++ implementation of typeof, then
> we need to include the C++ header <type_traits> for
> std::remove_reference_t.  This header is also likely to be used for
> other C++ implementations of type tricks, so we'll put it into the
> global includes.

For some reason, a couple of animals running gcc-15 or newer
(leafhopper, massasauga, parula) appear to be failing now because of
this.

ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wmissing-format-attribute -Wold-style-declaration -Wimplicit-fallthrough=5 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -Wmissing-variable-declarations -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 -Wstrict-prototypes -Wold-style-definition -fPIC -fvisibility=hidden -shared -o test_slru.so  test_slru.o test_multixact.o -L../../../../src/port -L../../../../src/common    -Wl,--as-needed -Wl,-rpath,'/home/bf/proj/bf/build-farm-17/HEAD/inst/lib',--enable-new-dtags -fvisibility=hidden 
In file included from ../../../../src/include/postgres.h:48,
                 from test_cplusplusext.cpp:18:
../../../../src/include/c.h:91:10: fatal error: type_traits: No such file or directory
   91 | #include <type_traits>
      |          ^~~~~~~~~~~~~
compilation terminated.
make[1]: *** [<builtin>: test_cplusplusext.o] Error 1
make[1]: Leaving directory '/home/bf/proj/bf/build-farm-17/HEAD/pgsql.build/src/test/modules/test_cplusplusext'

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

  29. Re: Change copyObject() to use typeof_unqual

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-13T15:56:39Z

    =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> For some reason, a couple of animals running gcc-15 or newer
> (leafhopper, massasauga, parula) appear to be failing now because of
> this.

They just started failing a day or two ago, so it's hard to blame
it on any code change we made.  I see that all three of those animals
are using "experimental" nightly builds of gcc, so it's reasonable to
assume that gcc's git tip is broken.  Or maybe something needs updated
in the recipe for replacing their gcc builds.

			regards, tom lane

  30. Re: Change copyObject() to use typeof_unqual

    Robins Tharakan <tharakan@gmail.com> — 2026-06-17T11:45:45Z

    Hi,

On Sun, 14 Jun 2026 at 01:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> > For some reason, a couple of animals running gcc-15 or newer
> > (leafhopper, massasauga, parula) appear to be failing now because of
> > this.
>
> They just started failing a day or two ago, so it's hard to blame
> it on any code change we made.  I see that all three of those animals
> are using "experimental" nightly builds of gcc, so it's reasonable to
> assume that gcc's git tip is broken.  Or maybe something needs updated
> in the recipe for replacing their gcc builds.


Earlier, since gcc HEAD was too noisy, I moved them all to gcc v15
assuming it'd be better. The gcc build script has been stable and there's
been no change in any of the machines recently, so I also wouldn't be
surprised if it is gcc again.

For now, I've taken them all offline and unless someone has a better
idea, I'll switch them to stay pinned to the recentmost gcc release
version - rationale being that if a tagged gcc release is buggy, it
may be interesting to know about.

-
robins | robins.in

  31. Re: Change copyObject() to use typeof_unqual

    Jelte Fennema <postgres@jeltef.nl> — 2026-06-17T12:11:24Z

    On Wed, 17 Jun 2026 at 13:46, Robins Tharakan <tharakan@gmail.com> wrote:
> Earlier, since gcc HEAD was too noisy, I moved them all to gcc v15
> assuming it'd be better. The gcc build script has been stable and there's
> been no change in any of the machines recently, so I also wouldn't be
> surprised if it is gcc again.
>
> For now, I've taken them all offline and unless someone has a better
> idea, I'll switch them to stay pinned to the recentmost gcc release
> version - rationale being that if a tagged gcc release is buggy, it
> may be interesting to know about.

FWIW the error that alvaro mentions suggests that either the C++
stdlib was not installed (i.e. some installation/configuration
problem) or that extern "C++" {...} is broken.