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

On Tue, Aug 13, 2024 at 6:23 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> Patch 3 makes sense too, some comments on the details:
> The #ifdefs and the LCONV_MEMBER stuff makes it a bit hard to follow
> what happens in each implementation strategy. I wonder if it would be
> more clear to duplicate more code.

I tried to make it easier to follow.

> There's a comment at the top of pg_locale.c ("!!! NOW HEAR THIS !!!")
> that needs to be removed or adjusted now.

Yeah. We can remove that PSA if we also fix up the equivalent code
for LC_TIME. First attempt at that attached.

> > * The POSIX standard explicitly says that it is undefined what happens if
> > * LC_MONETARY or LC_NUMERIC imply an encoding (codeset) different from
> > * that implied by LC_CTYPE. In practice, all Unix-ish platforms seem to
> > * believe that localeconv() should return strings that are encoded in the
> > * codeset implied by the LC_MONETARY or LC_NUMERIC locale name. Hence,
> > * once we have successfully collected the localeconv() results, we will
> > * convert them from that codeset to the desired server encoding.
>
> The patch loses this comment, leaving just a much shorter comment in the
> WIN32 implementation. But it still seems like a relevant comment for the
> !WIN32 implementation too.

New version makes it much clearer, and also is much more careful about
what exactly happens if you have mismatched encodings.

(Over in CF #3772 I was exploring the idea of banning the use of
locales that are not compatible with the database encoding. As far as
I can guess, that idea must have come from the time when Windows
didn't have native UTF-8 support. Now it does. There I was mostly
interested in killing all the whcar_t conversion code, but maybe we
could also delete a few lines of transcoding around here too?)