Re: Collation patch's handling of wcstombs/mbstowcs is sheerest fantasy - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Collation patch's handling of wcstombs/mbstowcs is sheerest fantasy
Date
Msg-id 1771.1303531117@sss.pgh.pa.us
Whole thread Raw
In response to Collation patch's handling of wcstombs/mbstowcs is sheerest fantasy  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Collation patch's handling of wcstombs/mbstowcs is sheerest fantasy  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
> else, this flat out does not work in non-default collations.  What's
> more, there doesn't seem to be any such thing as wcstombs_l or
> mbstowcs_l (at least my Fedora box hasn't got them), so this can't be
> fixed within the available glibc API.

I poked around a bit and found out that wcstombs_l and mbstowcs_l *do*
exist in some BSD-derived systems (in particular, OS X has 'em; and
Windows too).  Not clear why XBD didn't see fit to include them, because
so far as I can see there simply isn't any useful substitute.

What I think we need to do is:

* Redefine char2wchar and wchar2char as being like mbstowcs_l and
wcstombs_l (in particular, take pg_locale_t *not* a collation OID).

* Use mbstowcs_l and wcstombs_l where available.

* 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.  A quick look at the glibc source
for uselocale() suggests that it won't be too horribly inefficient.

Comments, better ideas?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Patch for pg_upgrade to turn off autovacuum
Next
From: David Christensen
Date:
Subject: Re: "stored procedures"