Postgres has been bitten by a few locale-related bugs, most recently via
libperl[0]. I had previously submitted this patchset in the bug thread
for the aforementioned bug, but here is a standalone submission for the
purposes of an eventual commitfest submission, and to get discussion
going. I was also flubbing up the commitfest bot with my patches. Sorry
Joe! I feel fairly good about the patch, but I think I need some more
testing and feedback. Localization is such a fickle beast.
I did leave one TODO because I need some input:
/* TODO: This does not handle "" as the locale */
check_locale() takes a canonname argument, which the caller expects to
be the "canonical name" of the locale the caller passed in. The
setlocale() man page is not very explicit about under what conditions
the return value is different from the input string, and I haven't found
much on the internet. Best I can tell is that the empty string is the
only input value that differs from the output value of setlocale(). If
that's the case, on Postmaster startup, I can query setlocale() for what
the empty string canonicalizes to for all the locale categories we care
about, and save them off. The other solution to the problem would be to
find the equivalent API in the uselocale() family of functions, but I am
under the impression that such an API doesn't exist given I haven't
found it yet.
Also, should we just remove HAVE_USELOCALE? It seems like Windows is the
only platform that doesn't support it. Then we can just use _WIN32
instead.
I do not think this should be backpatched. Please see Joe's patch in the
bug thread as a way to fix the libperl bug on pre-17 versions.
[0]: https://www.postgresql.org/message-id/17946-3e84cb577e9551c3%40postgresql.org
--
Tristan Partin
Neon (https://neon.tech)
