From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Steve Singer <ssinger(at)ca(dot)afilias(dot)info>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: JDBC connections to 9.1 |
Date: | 2011-04-18 14:57:07 |
Message-ID: | 22092.1303138627@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Bernd Helmle <mailings(at)oopsware(dot)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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-04-18 15:09:20 | Re: Typed table DDL loose ends |
Previous Message | Noah Misch | 2011-04-18 14:48:19 | Re: Typed table DDL loose ends |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-04-18 15:10:22 | Re: JDBC connections to 9.1 |
Previous Message | Bernd Helmle | 2011-04-18 14:34:04 | Re: JDBC connections to 9.1 |