From: "Noah Misch" <noah@leadboat.com>
> 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.)
Unfortunately, character set conversion is not possible until the database
session is established, since it requires system catalog access. Please the
comment in src/backend/utils/mb/mbutils.c:
* During backend startup we can't set client encoding because we (a)* can't look up the conversion functions, and (b)
maynot know the database* encoding yet either. So SetClientEncoding() just accepts anything and* remembers it for
InitializeClientEncoding()to apply later.
I guess that's why Tom-san suggested the same solution as my patch (as a
compromise) in the below thread, which is also a TODO item:
Re: encoding of PostgreSQL messages
http://www.postgresql.org/message-id/19896.1234107496@sss.pgh.pa.us
From: "Alvaro Herrera" <alvherre@2ndquadrant.com>
> The problem is that if there's an encoding mismatch, the message might
> be impossible to figure out. If the message is in english, at least it
> can be searched for in the web, or something -- the user might even find
> a page in which the english error string appears, with a native language
> explanation.
I feel like this, too. Being readable in English is better than being
unrecognizable.
Regards
MauMau
