Horton

Re: JDBC connections to 9.1

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bernd Helmle <mailings@oopsware.de>, Steve Singer <ssinger@ca.afilias.info>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>, pgsql-jdbc@postgresql.org
Date: 2011-04-18T15:10:22Z
Lists: pgsql-hackers 
On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bernd Helmle <mailings@oopsware.de> writes:
>> If i am reading it correct, it reads "UTF8" from the backend, while
>> expecting "UNICODE" only. Not sure what change has caused this,
>> though.
>
> I am --- when I redid the GUC assign_hook logic a few weeks ago,
> I changed the client_encoding code so that it shows the normalized
> (official) name of the encoding, not whatever random string the client
> sent over.  For instance, previous versions:
>
> regression=# set client_encoding = 'UnIcOdE';
> SET
> regression=# show client_encoding ;
>  client_encoding
> -----------------
>  UnIcOdE
> (1 row)
>
> versus HEAD:
>
> regression=# set client_encoding = 'UnIcOdE';
> SET
> regression=# show client_encoding ;
>  client_encoding
> -----------------
>  UTF8
> (1 row)
>
> I wasn't aware that JDBC would fail on that.  It's pretty annoying that
> it does, but maybe we should grin and bear it, ie revert the change to
> canonicalize the GUC's value?

Ouch.  I hate to revert that, since it seems like a clear improvement.
 But I also hate to break JDBC.  Ouch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company