On Wed, Feb 11, 2009 at 02:20:47PM +0900, Hiroshi Inoue wrote: > Tom Lane wrote: > > Hiroshi Inoue <inoue@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
