Tatsuo Ishii <ishii (AT) sraoss (DOT) co.jp> writes:
I'm far from an expert on this, but the gettext documentation indicates
that it tries to translate the .po file contents into whatever encoding
is implied by LC_CTYPE. The fact that the string passed to
utf8_to_iso8859_1 is not identical to the .po file contents indicates
that gettext is doing *something*. I'm a bit worried that this
translation could be out of step with what we will expect the
server_encoding to be --- but there's not any immediate evidence of
that.

Anyway, the real problem seems to be what to do if translation of an
error message to the client_encoding fails. That's clearly a risk even
if gettext has behaved perfectly.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
Correct. That is just one more reason to have server encoding,
LC_COLLATE, and LC_CTYPE matching. In practice, there is hardly a
reason to have LC_COLLATE and LC_CTYPE be different, so the problem
should not be that big.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly