On Wed, Aug 7, 2024 at 10:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Davis <pg...@j-davis.com> writes: > > But there are a couple problems: > > > 1. I don't think it's supported on Windows. > > Can't help with that, but surely Windows has some thread-safe way.
It does. It's not exactly the same, instead there is a thing you can call that puts setlocale() itself into a thread-local mode, but last time I checked that mode was missing on MinGW so that's a bit of an obstacle. How far can we get by using more _l() functions? For example, [1] shows a use of strftime() that I think can be converted to strftime_l() so that it doesn't depend on setlocale(). Since POSIX doesn't specify every obvious _l function, we might need to provide any missing wrappers that save/restore thread-locally with uselocale(). Windows doesn't have uselocale(), but it generally doesn't need such wrappers because it does have most of the obvious _l() functions. > > 2. I don't see a good way to canonicalize a locale name, like in > > check_locale(), which uses the result of setlocale(). > > What I can tell you about that is that check_locale's expectation > that setlocale does any useful canonicalization is mostly wishful > thinking [1]. On a lot of platforms you just get the input string > back again. If that's the only thing keeping us on setlocale, > I think we could drop it. (Perhaps we should do some canonicalization > of our own instead?) +1 I know it does something on Windows (we know the EDB installer gives it strings like "Language,Country" and it converts them to "Language_Country.Encoding", see various threads about it all going wrong), but I'm not sure it does anything we actually want to encourage. I'm hoping we can gradually screw it down so that we only have sane BCP 47 in the system on that OS, and I don't see why we wouldn't just use them verbatim. [1] https://www.postgresql.org/message-id/CA%2BhUKGJ%3Dca39Cg%3Dy%3DS89EaCYvvCF8NrZRO%3Duog-cnz0VzC6Kfg%40mail.gmail.com
