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