Laurenz Albe <laurenz.albe@xxxxxxxxxxx> writes: > On Mon, 2020-11-16 at 12:30 -0500, Tom Lane wrote: >> In this case, I see one use of the constant TRUE in collationcmds.c, >> but I wonder how come that's there given that we deprecated upper-case >> TRUE some time ago. I find it hard to believe that sprinkling "#include >> <stdbool.h>" into random places is either necessary (on modern platforms >> anyway) or a good idea (if we're not using <stdbool.h>, this seems pretty >> much guaranteed to break things); so I think the rest of that patch is >> foolhardy. > How about this patch? It fixes the problem for me. What's wrong with s/TRUE/true/ in get_icu_language_tag? (I have zero interest in undoing 6337865f3, which is what this patch would amount to.) A larger issue is that it looks like ICU68 may insist on importing <stdbool.h> in some headers. That's fine on the platforms where we use <stdbool.h> anyway, but it's distinctly not fine elsewhere. We might be able to work around that the same way that dfmgr.h does: /* * On macOS, <dlfcn.h> insists on including <stdbool.h>. If we're not * using stdbool, undef bool to undo the damage. */ #ifndef PG_USE_STDBOOL #ifdef bool #undef bool #endif #endif This is going to be hard to test without a platform that doesn't use <stdbool.h> though. [ starts booting up spare PPC Mac ... ] regards, tom lane