From: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: encoding of PostgreSQL messages |
Date: | 2009-02-12 13:28:38 |
Message-ID: | 49942406.1010608@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Tom Lane wrote:
>>> Reflecting on the bigger picture ... I would imagine that the vast
>>> majority of existing applications depend on client_encoding settings
>>> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
>>> just the default (== database encoding). I don't think a solution that
>>> penalizes those cases and makes only
not only but also the JDBC driver or the ODBC driver sends the
startup packet including the client_encoding. Libpq can be changed
to allow *client_encoding=xxxxx* definition in conninfo.
> the case of setting it via
>>> PGCLIENTENCODING work nicely is going to make very many people happy.
Not a few libraries/applications issue SET client_encoding to ...
immediately after the connection was establised. What's wrong with
urging such clients to eliminate the SET commands and use the nice
feature of FE/BE procotol?
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2009-02-12 13:33:29 | Re: Fwd: Need help in porting Oracle PL/SQL's OUT paramater based procedures |
Previous Message | Grzegorz Jaśkiewicz | 2009-02-12 13:27:48 | Re: Update table with random values from another table |