Re: Problem of a server gettext message. - Mailing list pgsql-hackers

From Hiroshi Saito
Subject Re: Problem of a server gettext message.
Date
Msg-id 015501c83c6b$6ce62b10$c601a8c0@HP22720319231
Whole thread Raw
In response to Problem of a server gettext message.  ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>)
List pgsql-hackers
Hi.

Yeah, As a part from which a problem happens, it is your suggestion.

This is only the check. 
http://winpg.jp/~saito/pg83/message_check/gtext2.c
Therefore, a message needed is acquirable in the next operation.
gtext2 C UTF-8
http://winpg.jp/~saito/pg83/message_check/codeset_utf8_msg.txt
gtext2 C EUC_JP
http://winpg.jp/~saito/pg83/message_check/codeset_eucjp_msg.txt

However, The check of accuracy is not settled yet. If all server encodings 
are possible, I will want to work. But but, It is not desirable that more 
encodings are intermingled as a log message.... Then, here is no still good 
method. Furthermore, a good solution plan is desired. probably..

Thanks!

Regards,
Hiroshi Saito

----- Original Message ----- 
From: "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>

> > GetText is conversion po(EUC_JP) to SJIS.

Yes.

> Are you sure about that?  Why would gettext be converting to SJIS,
when
> SJIS is nowhere in the environment it can see?

gettext is using GetACP () on Windows, wherever that gets it's info from
...
"chcp" did change the GetACP codepage in Hiroshi's example, but chcp
does not reflect in LC_*

Seems we may want to use bind_textdomain_codeset.

Andreas


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: [hensa22@yahoo.es: Re: [pgsql-es-ayuda] SLL error 100% cpu]
Next
From: Tom Lane
Date:
Subject: Re: [hensa22@yahoo.es: Re: [pgsql-es-ayuda] SLL error 100% cpu]