On Mon Jul 3, 2023 at 1:24 AM CDT, Thomas Munro wrote: > On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 27.06.23 17:02, Tristan Partin wrote: > > > This is a patch which implements an issue discussed in bug #17946[0]. It > > > doesn't fix the overarching issue of the bug, but merely a consistency > > > issue which was found while analyzing code by Heikki. I had originally > > > submitted the patch within that thread, but for visibility and the > > > purposes of the commitfest, I have re-sent it in its own thread. > > > > > > [0]: > > > https://www.postgresql.org/message-id/49dfcad8-90fa-8577-008f-d142e61af...@iki.fi > > > > I notice that HAVE_USELOCALE was introduced much later than > > HAVE_LOCALE_T, and at the time the code was already using uselocale(), > > so perhaps the introduction of HAVE_USELOCALE was unnecessary and should > > be reverted. > > > > 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. -- Tristan Partin Neon (https://neon.tech)