| 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: | Whole Thread | Raw Message | 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 |