Ops,my mistake in the mail thread.:-(
sorry.
=== send the mistake other thread ==
Hi.
My swift attack test was the MinGW environment.
But, Inoue-san suggestion.
1. MinGW+gcc build
HIROSHI=# set LC_TIME=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
-
日曜日
(1 行)
HIROSHI=# s
Hiroshi Saito wrote:
>> I thought this was supposed to be driven by LC_TIME now, not
>> LC_MESSAGES.
>
> Uga, yes yes!
>
> HIROSHI=# set LC_TIME=Ja;
> SET
> HIROSHI=# select to_char(now(),'TMDay');
> to_char
> -
> 土曜日
> (1 行)
>
> Thanks:-)
Great! Thanks for testing!
//Magnus
--
Sent
I thought this was supposed to be driven by LC_TIME now, not
LC_MESSAGES.
Uga, yes yes!
HIROSHI=# set LC_TIME=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
-
土曜日
(1 行)
Thanks:-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
"Hiroshi Saito" writes:
> HIROSHI=# set LC_MESSAGES=Ja;
> SET
> HIROSHI=# select to_char(now(),'TMDay');
> to_char
> --
> Saturday
> (1 è¡)
I thought this was supposed to be driven by LC_TIME now, not
LC_MESSAGES.
regards, tom lane
--
Sent via pgsql-hackers m
Hi.
Thanks all.
I tried CVS-HEAD now.
HIROSHI=# select to_char(now(),'TMDay');
to_char
--
Saturday
(1 行)
HIROSHI=# set LC_MESSAGES=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
--
Saturday
(1 行)
===
ITAGAKI Takahiro wrote:
> Hiroshi Inoue wrote:
>
>> Seems LC_CTYPE and LC_TIME should be convertible even though we use
>> wcsftime (which internally calls strftime?).
>
> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> (at least encoding) on Windows.
>
> The attached p
ITAGAKI Takahiro wrote:
Magnus Hagander wrote:
ITAGAKI Takahiro wrote:
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
Hmm. Is this actually cleaner than using the original method as
suggested? Because if I understand things right, that
Magnus Hagander wrote:
> ITAGAKI Takahiro wrote:
> > Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> > (at least encoding) on Windows.
> >
> Hmm. Is this actually cleaner than using the original method as
> suggested? Because if I understand things right, that version d
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Hiroshi Inoue wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
shouldn
I've also thought a similar implementation but there seems
a problem of efficiency.
As far as I see wcsftime() is almost = strftime() + mbstowcs()
and so using strftime() is effective at least for the following
cases.
1) LC_CTIME is "C".
2) LC_CTYPE != C and the database encoding != UTF-8. In th
ITAGAKI Takahiro wrote:
Hiroshi Inoue wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The attached patch is an updat
ITAGAKI Takahiro wrote:
> Hiroshi Inoue wrote:
>
>> Seems LC_CTYPE and LC_TIME should be convertible even though we use
>> wcsftime (which internally calls strftime?).
>
> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> (at least encoding) on Windows.
>
> The attached p
ITAGAKI Takahiro wrote:
>
> Hiroshi Inoue wrote:
>
> > Seems LC_CTYPE and LC_TIME should be convertible even though we use
> > wcsftime (which internally calls strftime?).
>
> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> (at least encoding) on Windows.
shouldn't thi
Hiroshi Inoue wrote:
> Seems LC_CTYPE and LC_TIME should be convertible even though we use
> wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The attached patch is an updated version to fix cache
14 matches
Mail list logo