On Mon, Apr 19, 2010 at 03:59, Takahiro Itagaki
<itagaki.takah...@oss.ntt.co.jp> wrote:
>
> Magnus Hagander <mag...@hagander.net> wrote:
>
>> But I'm unsure how that would work. We're talking about the output of
>> localeconv(), right? I don't see a version of localeconv() that does
>> wide chars anywhere. (You can't just set LC_CTYPE and use the regular
>> function - Windows has a separate set of functions for dealing with
>> UTF16).
>
> Yeah, msvcrt doesn't have wlocaleconv :-( . Since localeconv() returns
> characters in the encoding specified in LC_TYPE, we need to hande the
> issue with codes something like:
>
>    1. setlocale(LC_CTYPE, lc_monetary)
>    2. setlocale(LC_MONETARY, lc_monetary)
>    3. lc = localeconv()
>    4. pg_do_encoding_conversion(lc->xxx,
>          FROM pg_get_encoding_from_locale(lc_monetary),
>          TO GetDatabaseEncoding())
>    5. Revert LC_CTYPE and LC_MONETARY.
>
>
> Another idea is to use GetLocaleInfoW() [1], that is win32 native locale
> functions, instead of the libc one. It returns locale characters in wide
> chars, so we can safely convert them as UTF16->UTF8->db. But it requires
> an additional branch in our locale codes only for Windows.

If we can go UTF16->db directly, it might be a good idea. If we're
going via UTF8 anyway, I doubt it's going to be worth it.

Let's work off what we have now to start with at least. Bruce, can you
comment on that thing about the extra parameter? And UTF8?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to