From: "Noah Misch" <n...@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) may not 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.1234107...@sss.pgh.pa.us
From: "Alvaro Herrera" <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
