On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Bernd Helmle <maili...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
