Re: encoding of PostgreSQL messages

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: encoding of PostgreSQL messages
Date: 2009-02-12 14:01:23
Message-ID: 20090212140123.GC3786@merkur.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Feb 11, 2009 at 02:20:47PM +0900, Hiroshi Inoue wrote:

> Tom Lane wrote:
> > Hiroshi Inoue <inoue(at)tpf(dot)co(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Kempter 2009-02-12 15:09:38 covering indexes?
Previous Message Karsten Hilbert 2009-02-12 13:57:28 Re: encoding of PostgreSQL messages