On Tue, Dec 17, 2013 at 01:42:08PM -0500, Bruce Momjian wrote:
> On Fri, Dec 13, 2013 at 10:41:17PM +0900, MauMau wrote:
> > [Cause]
> > While the session is being established, the server cannot use the
> > client encoding for message conversion yet, because it cannot access
> > system catalogs to retrieve conversion functions. So, the server
> > sends messages to the client without conversion. In the above
> > example, the server sends Japanese UTF-8 messages to psql, which
> > expects those messages in SJIS.
Better to attack that directly. Arrange to apply any client_encoding named in
the startup packet earlier, before authentication. This relates to the TODO
item "Let the client indicate character encoding of database names, user
names, and passwords". (I expect such an endeavor to be tricky.)
> > [Fix]
> > Disable message localization during session startup. In other
> > words, messages are output in English until the database session is
> > established.
>
> I think the question is whether the server encoding or English are
> likely to be better for the average client. My bet is that the server
> encoding is more likely correct.
>
> However, you are right that English/ASCII at least will always be
> viewable, while there are many server/client combinations that will
> produce unreadable characters.
>
> I would be interested to hear other people's experience with this.
I don't have a sufficient sense of multilingualism among our users to know
whether English/ASCII messages would be more useful, on average, than
localized messages in the server encoding. Forcing English/ASCII does worsen
behavior in the frequent situation where client encoding will match server
encoding. I lean toward retaining the status quo of delivering localized
messages in the server encoding.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
