Group: pgsql.hackers


Subject: Problem of a server gettext message.
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/10/2007 5:05:28 PM
Peter Eisentraut <peter_e@gmx.net> writes: > When the server wants to send an error message to the client, it will > convert them from the server to the client encoding. The English > messages are ASCII, so this will work, because server encodings are > required to be ASCII compatible. The result of the gettext calls, > however, is encoded in EUC-JP, so the server will take the EUC-JP > bytes and attempt to do a UTF-8 to SJIS conversion on them. This will > cause a crash. The problem here basically comes from the fact that gettext looks to LC_CTYPE to decide what encoding it's supposed to convert to (and I suppose it punts when LC_CTYPE = C). Does it have a way by which we could override that, to tell it the actual DB encoding regardless of the locale environment? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

Subject: Problem of a server gettext message.
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/10/2007 10:53:52 PM
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: > Probably no. > GetText is conversion po(EUC_JP) to SJIS. Then, The stderr output of a server is > outputted without an error to log by it. That's right message with it similar to start-up. > However, The conversion obstacle of a message is encountered at the time of the > conditions returned to a client. Conversion of the step of the following it takes place. > 1. iconv(GetText) > po(EUC_JP) to SJIS. > 2. message to client > UTF8(server encoding) to SJIS(client encoding) > But, this character that should be UTF-8 is a SJIS message(1.). > It causes an error. Are you sure about that? Why would gettext be converting to SJIS, when SJIS is nowhere in the environment it can see? I believe that Peter's hypothesis is that gettext is leaving the string in EUC_JP because it sees locale = C and so has no basis for doing any conversion. We still end up with a failure, because the basic problem is that the string isn't UTF8, but it's important to be sure we understand the exact mechanism. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match