Re: Change copyObject() to use typeof_unqual
| От | Tom Lane |
|---|---|
| Тема | Re: Change copyObject() to use typeof_unqual |
| Дата | |
| Msg-id | 14523.1773675135@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Change copyObject() to use typeof_unqual (Jelte Fennema-Nio <postgres@jeltef.nl>) |
| Ответы |
Re: Change copyObject() to use typeof_unqual
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: