Tom Lane wrote:
> Peter Eisentraut <peter_e@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