Tom Lane wrote: > Peter Eisentraut <pete...@gmx.net> writes: >> Bruce Momjian wrote: >>> Can someone comment on this? > >> I think we have discussed more proper solutions earlier in this thread. >> IMO the best approach would be for the client to include the client >> encoding in the startup package. > > Huh? Clients already do that (or at least some are capable of it,
> including libpq). What is a recommended way to do it using libpq, via "options" parameter or "PGCLIENTENCOIDNG" environment value? > The hard problems are (1) there's still a "before", > ie we might fail before scanning the options in the packet, and (2) > the sent encoding might itself be invalid, and you still have to report > that somehow. > > I believe the only real "fix" is to guarantee that messages are sent > as untranslated ASCII until we have sent an encoding indicator at > the end of the startup sequence. Which has its own pretty clear > downside: no more translation of authorization failures. I'm afraid I'm misunderstanding your point. 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(). Comments? regards, Hiroshi Inoue -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
