Hi,
Over on the discussion thread about remaining setlocale() work[1], I
wrote out some long boring theories about $SUBJECT. Here are some
draft patches to try those theories out, and make a commitfest entry.
nl_langinfo_l() is a trivial drop-in replacement, and
pg_localeconv_r() has 4 different implementation strategies:
1. Windows, with ugly _configthreadlocale() and thread-local result.
2. Glibc, with nice nl_langinfo_l() extensions.
3. macOS/*BSD, with nice localeconv_l().
4. Baseline POSIX: uselocale() + localeconv() + honking great lock.
In reality it'd just be Solaris running #4 (and AIX if it comes back).
Whether they truly implement it as pessimally as the standard allows,
who knows... you could drop the lock if you somehow knew that they
returned a pointer to thread-local storage or a member of the locale_t
object.
[1] https://www.postgresql.org/message-id/flat/4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel%40j-davis.com
