Re: encoding of PostgreSQL messages

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

In response to

Responses

Browse pgsql-general by date

  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