Tom Lane wrote:
> Hiroshi Inoue <inoue@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
Removing step 1 resolves the penalty. In the first place step 1
comes from your or Karsten's suggestion.
> 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.
Maybe not enough currently because collaboration between the backend
and clients is needed to solve this problem ovbiously. The backend
should provide clients the way to specify the client_encoding on the
fly which can be applied to authorization failure messages. Then
clients which are eager to solve this problem would use the way.
Using the information in the startup message is almost unique way
to achieve it.
regards,
Hiroshi Inoue