Horton

Thread-safe nl_langinfo() and localeconv()

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-08-13T05:45:14Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Fix "‘static’ is not at beginning of declaration" warning

  2. Use thread-safe strftime_l() instead of strftime().

  3. Provide thread-safe pg_localeconv_r().

  4. Harmonize MinGW CODESET lookup with MSVC.

  5. Include <xlocale.h> for macOS, take II.

  6. Use thread-safe nl_langinfo_l(), not nl_langinfo().

  7. All POSIX systems have langinfo.h and CODESET.