Re: [HACKERS] JDBC connections to 9.1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] JDBC connections to 9.1
Дата
Msg-id 22092.1303138627@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] JDBC connections to 9.1  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] JDBC connections to 9.1  (Dave Cramer <pg@fastcrypt.com>)
Re: [HACKERS] JDBC connections to 9.1  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: [HACKERS] JDBC connections to 9.1  (Mike Fowler <mike@mlfowler.com>)
Список pgsql-jdbc
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?

            regards, tom lane

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: "Kasprzyk Maciej-FHC368"
Дата:
Сообщение: feature request: make support for java.sql.Types.DISTINCT optional
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] JDBC connections to 9.1