Re: [HACKERS] JDBC connections to 9.1

Поиск
Список
Период
Сортировка
Искать
От
Kevin Grittner
Тема
Re: [HACKERS] JDBC connections to 9.1
Дата
Msg-id
4DAC0EE1020000250003C947@gw.wicourts.gov
Ответ на
Список
Дерево обсуждения
Re: [HACKERS] JDBC connections to 9.1 Tom Lane <tgl@sss.pgh.pa.us>
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>
Re: [HACKERS] JDBC connections to 9.1 Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] JDBC connections to 9.1 Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] JDBC connections to 9.1 Mike Fowler <mike@mlfowler.com>
Re: [HACKERS] JDBC connections to 9.1 Dave Cramer <pg@fastcrypt.com>
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 Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] JDBC connections to 9.1 Dave Cramer <pg@fastcrypt.com>
Re: [HACKERS] JDBC connections to 9.1 Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] JDBC connections to 9.1 Mike Fowler <mike@mlfowler.com>
Re: [HACKERS] JDBC connections to 9.1 Kris Jurka <books@ejurka.com>
Re: [HACKERS] JDBC connections to 9.1 Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] JDBC connections to 9.1 Kris Jurka <books@ejurka.com>
Re: [HACKERS] JDBC connections to 9.1 Tom Lane <tgl@sss.pgh.pa.us>
Tom Lane  wrote:
 
> 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
 
The whole area of character sets and encoding schemes is confusing
enough without accepting a character set name as an encoding scheme
specification.  I'll bet that in five or ten years we'll be
accepting more than one encoding scheme for the Unicode character
set.
 
> 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?
 
Can we fix the JDBC driver rather than reverting this?  Long run,
I'd be in favor of just rejecting a character set name as a client
encoding specification.  I think inferring one is being generous.
 
-Kevin
В списке pgsql-jdbc по дате отправления
От: Dave Cramer
Дата:
От: Mike Fowler
Дата:
FAQ