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)
