Re: Solve a problem of LC_TIME of windows. - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: Solve a problem of LC_TIME of windows.
Date
Msg-id 48DA044D.10005@hagander.net
Whole thread Raw
In response to Solve a problem of LC_TIME of windows.  ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>)
Responses Re: Solve a problem of LC_TIME of windows.  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
Hiroshi Saito wrote:
> Hi.
>
> I have problem of LC_TIME of windows.(CVS-HEAD)
>
> As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is
> expressed.)
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png
>
>
> As for Version 8.4. It came to be used by Tom-san in strftime of
> Native-windowsAPI.
> It is good improvement.! But, strftime of Native returns a result by
> CODEPAGE of
> environment of operation by Windows with LC_TIME. In Japanese
> environment, return
> value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by
> SERVER_ENCODING.:-(
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png
>
> Then, I'm proposal patch. It is solved splendidly.
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt
>
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt

In principle, I think this patch looks good.

Do you (or somebody else) have an example where this breaks in an
encoding where I can actually understand the characters, though ;-) That
would make testing a whole lot easier...

Also, the patch needs error checking. strftime() can fail, and the
multibyte conversion functions can certainly fail. That will need to be
added.

//Magnus

pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Subtransaction commits and Hot Standby
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Subtransaction commits and Hot Standby