From: | "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> |
---|---|
To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] Solve a problem of LC_TIME of windows. |
Date: | 2008-11-16 13:36:50 |
Message-ID: | 446F4763B989489C9B626D21AB9F6C7F@HIRO57887DE653 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hi.
All suggestion is appropriate and has been checked.
CVS-HEAD was examined by MinGW.
$ make check NO_LOCALE=true
...
=======================
All 118 tests passed.
=======================
Then, It continues and a review is desired.
Thanks!
Regatrds,
Hiroshi Saito
----- Original Message -----
From: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
> Hi ITAGAKI-san.
>
> Sorry, very late reaction..
> I lost time resources in an individual my machine trouble and busyness.:-(
> Now, I appreciate your exact work. ! Then, I desire the best patch for PostgreSQL.
> Probably, I think that it is finally helpful in not a problem of only Japan but many countries.
> Tom-san, and Alvaro-san, Magnus-san understands the essence of this problem.
> Therefore, the suggestion is expected for me.
>
> Anyway, thank you very much.!!
>
> Regards,
> Hiroshi Saito
>
> ----- Original Message -----
> From: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
>
>
>>
>> "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
>>
>>> i'm confused, original patch has this signature:
>>> + conv_strftime(char *src, size_t len, const char *format, const struct tm *tm)
>>> your's has:
>>> +strftime_win32(char *dst, size_t dstlen, const char *format, const
>>
>>> you change all src for dst, just a variable name decision but a
>>> radical one... why was that (i honestly doesn't understand this patch
>>> very well ;)?
>>
>> That's because the first argument is not an input buffer,
>> but an output buffer. MSDN also calls it 'strDest'.
>> http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx
>> Linux manpage calls it 's', but I think it means String, not Src.
>> http://man.cx/strftime
>>
>> If you can review the patch, please use the attached one instead.
>> I modified it in response to the discussion of pg_do_encoding_conversion.
>>
>>
>> BTW, I cannot understand the comment in the function head,
>>
>> + * result is obtained by locale setup of LC_TIME in the environment
>> + * of windows at present CP_ACP. Therefore, conversion is needed
>> + * for SERVER_ENCODING. SJIS which is not especially made to server
>> + * encoding in Japan returns.
>>
>> but it probably says:
>>
>> ----
>> strftime in Windows returns in CP_ACP encoding, but it could be
>> different from SERVER_ENCODING. Especially, Windows Japanese edition
>> requires conversions because it uses SJIS as CP_ACP, but we don't
>> support SJIS as a server encoding.
>> ----
>>
>> I hope you would review my English not only C ;-)
>>
>> Regards,
>> ---
>> ITAGAKI Takahiro
>> NTT Open Source Software Center
>>
>>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
Attachment | Content-Type | Size |
---|---|---|
pg_locale_patch-v5 | application/octet-stream | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-11-16 14:15:28 | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; |
Previous Message | Martijn van Oosterhout | 2008-11-16 11:08:57 | Re: Block-level CRC checks |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-11-17 13:51:30 | Re: [PATCHES] Infrastructure changes for recovery (v8) |
Previous Message | Andrew Dunstan | 2008-11-11 23:09:09 | Re: [PATCHES] odd output in restore mode |