Re: JDBC connections to 9.1

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bernd Helmle" <mailings(at)oopsware(dot)de>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Steve Singer" <ssinger(at)ca(dot)afilias(dot)info>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>, <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC connections to 9.1
Date: 2011-04-18 15:13:53
Message-ID: 4DAC0EE1020000250003C947@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike Fowler 2011-04-18 15:14:08 Re: [JDBC] JDBC connections to 9.1
Previous Message Dave Cramer 2011-04-18 15:11:26 Re: [JDBC] JDBC connections to 9.1

Browse pgsql-jdbc by date

  From Date Subject
Next Message Mike Fowler 2011-04-18 15:14:08 Re: [JDBC] JDBC connections to 9.1
Previous Message Dave Cramer 2011-04-18 15:11:26 Re: [JDBC] JDBC connections to 9.1