Horton

Re: Thread-safe nl_langinfo() and localeconv()

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Thomas Munro <thomas.munro@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-31T13:52:44Z
Lists: pgsql-hackers 
Peter Eisentraut <peter@eisentraut.org> writes:
> I'm not sure what to do with this.  If setlocale() and newlocale() 
> indeed behave differently in what set of locale names they accept, then 
> technically we ought to test both of them, since we do use both of them 
> later on.  Or maybe we push on with the effort to get rid of setlocale() 
> calls and then just worry about testing newlocale() (as this patch 
> does).  But right now, if newlocale() is more permissive, then we could 
> accept locale names that will later fail setlocale() calls, which might 
> be a problem.

I think the clear answer is "let's stop using setlocale(), and then
not have to worry about any behavioral differences".

			regards, tom lane

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.