On fre, 2011-04-22 at 16:32 -0400, Tom Lane wrote:
It's possible that things are not too broken in practice, because it's
likely that the transformations done by these functions only depend on
the encoding indicated by LC_CTYPE, and we (try to) enforce that all
locales used in a given database
On lör, 2011-04-23 at 11:37 -0400, Tom Lane wrote:
I wrote:
* Where they're not, install the locale_t with uselocale(), do
mbstowcs or wcstombs, and revert to the former locale_t setting.
This is ugly as sin, and not thread-safe, but of course lots of
the backend is not thread-safe.
I wrote:
* Where they're not, install the locale_t with uselocale(), do
mbstowcs or wcstombs, and revert to the former locale_t setting.
This is ugly as sin, and not thread-safe, but of course lots of
the backend is not thread-safe.
I've been corrected on that: uselocale() *is* thread safe,
I just noticed that the collation patch has modified char2wchar and
wchar2char to accept a collation OID as argument ... but it hasn't done
anything to make those arguments actually work. Since those functions
depend on wcstombs and mbstowcs, which respond to LC_CTYPE and nothing
else, this flat
I wrote:
I just noticed that the collation patch has modified char2wchar and
wchar2char to accept a collation OID as argument ... but it hasn't done
anything to make those arguments actually work. Since those functions
depend on wcstombs and mbstowcs, which respond to LC_CTYPE and nothing
