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
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 |