Re: encoding of PostgreSQL messages

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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