Hiroshi Inoue <inoue@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
