On Wed, Feb 11, 2009 at 02:20:47PM +0900, Hiroshi Inoue wrote:
> 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.
I have tried that but it didn't work out for some reason.
> Removing step 1 resolves the penalty. In the first place step 1
> comes from your or Karsten's suggestion.
Not quite. My suggestion was to not *translate* strings (and
assume 7-bit ascii) until the client encoding is known.
> 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.
Sounds good to me as far as I can see.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346