Re: Solve a problem of LC_TIME of windows.

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Solve a problem of LC_TIME of windows.
Дата
Msg-id 4964DA42.9040401@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Solve a problem of LC_TIME of windows.  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
ITAGAKI Takahiro wrote:
> Hiroshi Inoue <inoue@tpf.co.jp> 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_locale_time().
> Now it sets LC_TIME and LC_CTYPE to the specified locale and restore
> them at end of the function. I tested the patch on Windows XP Japanese
> Edition (SJIS) with UTF-8 and EUCJP databases, and worked expectedly.

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 this   case the current restriction of PostgreSQL requires that
 the database encoding matches the encoding of the LC_CTYPE.
 

We seem to be able to call strftime() directly in above cases.

Comments ?

regards,
Hiroshi Inoue


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: float8 strtod weirdness
Следующее
От: David Fetter
Дата:
Сообщение: Re: about truncate