Hiroshi Inoue <in...@tpf.co.jp> writes:
> I'm thinking of the following steps in the backend code.
> 1.Set LC_MESSAGES to "C" until the client_encoding is
> determined.
> 2.When a client_encoding is specifed in the startup
> message, bind the corrsponding codeset to the
> textdomain and set LC_MESSAGES to the specified one
> in the startup message or restore the LC_MESSAGES
> overridden by step 1 before authorization step.
> Then we can see properly localized authorization
> failure messages.
> 3.Reset LC_MESSAGES to the current one in Initialize
> ClientEncoding() and unbind the codeset if necessary
> in SetDatabaseEncoding().
Reflecting on the bigger picture ... I would imagine that the vast
majority of existing applications depend on client_encoding settings
that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
just the default (== database encoding). I don't think a solution that
penalizes those cases and makes only the case of setting it via
PGCLIENTENCODING work nicely is going to make very many people happy.
Mind you, I don't really know how to do better, but I do see that the
case of client_encoding being specified in the startup message is
not going to help enough people to be particularly useful.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
