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
