Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Takahiro Itagaki wrote:
> >> Takahiro Itagaki wrote:
> >>
> >>> Revised patch attached. Please test it.
> >> I applied this version of the patch.
> >> Please check wheter the bug is fixed and any buildfarm failures.
> >
> > Great. I have merged in
Bruce Momjian wrote:
Takahiro Itagaki wrote:
Takahiro Itagaki wrote:
Revised patch attached. Please test it.
I applied this version of the patch.
Please check wheter the bug is fixed and any buildfarm failures.
Great. I have merged in my C comments into the code with the attached
patch so
Takahiro Itagaki wrote:
>
> Takahiro Itagaki wrote:
>
> > Revised patch attached. Please test it.
>
> I applied this version of the patch.
> Please check wheter the bug is fixed and any buildfarm failures.
Great. I have merged in my C comments into the code with the attached
patch so we remem
Takahiro Itagaki wrote:
> Revised patch attached. Please test it.
I applied this version of the patch.
Please check wheter the bug is fixed and any buildfarm failures.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Hiroshi Inoue wrote:
> 1. How does it work when LC_MONETARY and LC_NUMERIC are different?
I think it is rarely used, but possible. Fixed.
> 2. Calling db_encoding_strdup() for lconv->grouping is appropriate?
Ah, we didn't need it. Removed.
Revised patch attached. Please test it.
Regards,
--
Takahiro Itagaki wrote:
Magnus Hagander wrote:
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_MONE
Magnus Hagander wrote:
> > 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
Takahiro Itagaki wrote:
>
> Magnus Hagander wrote:
>
> > > 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 GetDatabaseEn
Magnus Hagander wrote:
> > One new idea would be to set LC_CTYPE to UTF16/widechars unconditionally
> > on Win32 and then just convert that always to the server encoding with
> > win32_wchar_to_db_encoding(), instead of using the encoding from
> > LC_MONETARY to set LC_CTYPE and having to do double
Magnus Hagander wrote:
> > 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_MO
On Mon, Apr 19, 2010 at 03:59, Takahiro Itagaki
wrote:
>
> Magnus Hagander 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 reg
Magnus Hagander 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 d
On Mon, Mar 22, 2010 at 9:14 PM, Bruce Momjian wrote:
> Takahiro Itagaki wrote:
>>
>> Bruce Momjian wrote:
>>
>> > Takahiro Itagaki wrote:
>> > > Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
>> > > db_encoding_strdup() with the function. Like this:
>> >
>> > OK, I don't
Takahiro Itagaki wrote:
>
> Bruce Momjian wrote:
>
> > Takahiro Itagaki wrote:
> > > Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
> > > db_encoding_strdup() with the function. Like this:
> >
> > OK, I don't have any Win32 people testing this patch so if we want this
>
Bruce Momjian wrote:
> Takahiro Itagaki wrote:
> > Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
> > db_encoding_strdup() with the function. Like this:
>
> OK, I don't have any Win32 people testing this patch so if we want this
> fixed for 9.0 someone is going to have t
Takahiro Itagaki wrote:
>
> Bruce Momjian wrote:
>
> > OK, I have created a new function, win32_wchar_to_db_encoding(), to
> > share the conversion from wide characters to the database encoding.
> > New patch attached.
>
> Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
>
Bruce Momjian wrote:
> OK, I have created a new function, win32_wchar_to_db_encoding(), to
> share the conversion from wide characters to the database encoding.
> New patch attached.
Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
db_encoding_strdup() with the function. L
Hiroshi Inoue wrote:
> I need someone with WIN32 experience to review and test this patch.
> >>> I don't understand why cache_locale_time() works on Windows. It sets
> >>> the LC_CTYPE but does not do any encoding coversion.
> >> Doesn't strftime_win32 do the conversion?
> >
> > Oh, I now se
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah,
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Hiroshi Inoue wrote:
> >>> Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> >> Where are we on this issue?
> > Oops I forgot it completely.
> > I have a little improved version and w
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah, very good. Thanks.
Attached is an improve
Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > > Hiroshi Inoue wrote:
> > >> Bruce Momjian wrote:
> > >>> Where are we on this issue?
> > >> Oops I forgot it completely.
> > >> I have a little improved version and would post it tonight.
> > >
> > > Ah, very good. Thanks.
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Hiroshi Inoue wrote:
> >> Bruce Momjian wrote:
> >>> Where are we on this issue?
> >> Oops I forgot it completely.
> >> I have a little improved version and would post it tonight.
> >
> > Ah, very good. Thanks.
>
> Attached is an improved version.
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Tom Lane wrote:
>>> * This seems to be assuming that the user has set LC_MONETARY and
>>> LC_NUMERIC the same. What if they're different?
>
>> Strictky speaking they should be handled individually.
>
> I thought about this some more, and I wonder why y
Hiroshi Inoue writes:
> Tom Lane wrote:
>> * This seems to be assuming that the user has set LC_MONETARY and
>> LC_NUMERIC the same. What if they're different?
> Strictky speaking they should be handled individually.
I thought about this some more, and I wonder why you did it like this at
all.
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Tom Lane wrote:
>>> I think what this suggests is that there probably needs to be some
>>> encoding conversion logic near the places we examine localeconv()
>>> output.
>
>> Attached is a patch to the current CVS.
>> It uses a similar way like LC_TIME st
Hiroshi Inoue writes:
> Tom Lane wrote:
>> I think what this suggests is that there probably needs to be some
>> encoding conversion logic near the places we examine localeconv()
>> output.
> Attached is a patch to the current CVS.
> It uses a similar way like LC_TIME stuff does.
I'm not really
27 matches
Mail list logo
