On Mon Jul 3, 2023 at 9:21 AM CDT, Peter Eisentraut wrote: > On 03.07.23 15:21, Tristan Partin wrote: > >>> I think it would be better to keep HAVE_LOCALE_T as encompassing any of > >>> the various locale_t-using functions, rather than using HAVE_USELOCALE > >>> as a proxy for them. Otherwise you create weird situations like having > >>> #ifdef HAVE_WCSTOMBS_L inside #ifdef HAVE_USELOCALE, which doesn't make > >>> sense, I think. > >> I propose[1] that we get rid of HAVE_LOCALE_T completely and make > >> "libc" provider support unconditional. It's standardised, and every > >> target system has it, even Windows. But Windows doesn't have > >> uselocale(). > >> > >> [1]https://www.postgresql.org/message-id/flat/CA%2BhUKGL7CmmzeRhoirzjECmOdABVFTn8fo6gEOaFRF1Oxey6Hw%40mail.gmail.com#aef2f2274b28ff8a36f9b8a598e3cec0 > > I think keeping HAVE_USELOCALE is important for the Windows case as > > mentioned. I need it for my localization work where I am ripping out > > setlocale() on non-Windows. > > The current code is structured > > #ifdef HAVE_LOCALE_T > #ifdef HAVE_WCSTOMBS_L > wcstombs_l(...); > #else > uselocale(...); > #endif > #else > elog(ERROR); > #endif > > If you just replace HAVE_LOCALE_T with HAVE_USELOCALE, then this would > penalize a platform that has wcstombs_l(), but not uselocale(). I think > the correct structure would be > > #if defined(HAVE_WCSTOMBS_L) > wcstombs_l(...); > #elif defined(HAVE_USELOCALE) > uselocale(...); > #else > elog(ERROR); > #endif
That makes sense to me. I gave it some more thought. Maybe it makes more sense to just completely drop HAVE_USELOCALE as mentioned, and protect calls to it with #ifdef WIN32 or whatever the macro is. HAVE_USELOCALE might be more descriptive, but I don't really care that much either way. -- Tristan Partin Neon (https://neon.tech)
