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? > > regards, tom lane >
Older drivers will fail for sure. We can fix newer drivers, but if we leave it we will see a slew of bug reports. The reason the driver does this is to guarantee the client encoding is unicode. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
