Re: JDBC connections to 9.1
От | Robert Haas |
---|---|
Тема | Re: JDBC connections to 9.1 |
Дата | |
Msg-id | BANLkTi=0phhjdrXdu6Wb9LkCZw8D7ujiqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JDBC connections to 9.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: