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>) |
Список | pgsql-jdbc |
Tom Lane <tgl@sss.pgh.pa.us> 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 по дате отправления: