JDBC connections to 9.1

Started by Steve Singerover 14 years ago23 messages
#1Steve Singer
ssinger@ca.afilias.info

I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.

There is nothing obvious at http://jdbc.postgresql.org or in the 9.1
alpha release notes that indicate a newer JDBC driver will be required.

Have other people seen similar issues?

If 9.1 does require a JDBC driver upgrade then it would be good if an
updated driver was posted before we start encouraging people to test
their applications with the beta.

Caused by: org.postgresql.util.PSQLException: Protocol error. Session
setup failed.
at
org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:496)
at
org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112)
at
org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
at
org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java:24)
at org.postgresql.Driver.makeConnection(Driver.java:393)
at org.postgresql.Driver.connect(Driver.java:267)
at java.sql.DriverManager.getConnection(DriverManager.java:620)
at java.sql.DriverManager.getConnection(DriverManager.java:200)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161)
... 14 more

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Steve Singer (#1)
Re: JDBC connections to 9.1

Steve Singer <ssinger@ca.afilias.info> writes:

I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.

Hmm, what shows up in the postmaster log?

regards, tom lane

#3Bernd Helmle
mailings@oopsware.de
In reply to: Tom Lane (#2)
Re: JDBC connections to 9.1

--On 18. April 2011 09:44:38 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote:

I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.

Hmm, what shows up in the postmaster log?

A quick check with an application here gives the following with JDBC
loglevel=2

16:09:47.910 (1) PostgreSQL 9.1devel JDBC4 (build 900)
16:09:47.914 (1) Trying to establish a protocol version 3 connection to
localhost:5438
16:09:47.930 (1) FE=> StartupPacket(user=bernd, database=mailstore,
client_encoding=UNICODE, DateStyle=ISO, extra_float_digits=2)
16:09:47.933 (1) <=BE AuthenticationOk
16:09:47.942 (1) <=BE ParameterStatus(application_name = )
16:09:47.942 (1) <=BE ParameterStatus(client_encoding = UTF8)
org.postgresql.util.PSQLException: Protocol error. Session setup failed.
at
org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:498)
at
org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112)
at
org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
at
org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
at
org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22)
at
org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:32)
at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24)
at org.postgresql.Driver.makeConnection(Driver.java:393)
at org.postgresql.Driver.connect(Driver.java:267)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at de.oopsware.mailstore.PGSQLMailstore.connect(Unknown Source)
at de.oopsware.mailstore.PGSQLMailstore.connect(Unknown Source)
at mailstore.main(Unknown Source)
SQLException: SQLState(08P01)
getConnection failed: org.postgresql.util.PSQLException: Protocol error.
Session setup failed.
org.postgresql.util.PSQLException: Protocol error. Session setup failed.

Hmm, seems it stumbles while reading client_encoding....

--
Thanks

Bernd

#4Steve Singer
ssinger@ca.afilias.info
In reply to: Tom Lane (#2)
Re: JDBC connections to 9.1

On 11-04-18 09:44 AM, Tom Lane wrote:

Steve Singer<ssinger@ca.afilias.info> writes:

I'm getting JDBC exceptions when I try to connect to 9.1 (master) with
the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0.

Hmm, what shows up in the postmaster log?

regards, tom lane

LOG: unexpected EOF on client connection

#5Devrim GÜNDÜZ
devrim@gunduz.org
In reply to: Bernd Helmle (#3)
Re: JDBC connections to 9.1

On Mon, 2011-04-18 at 16:17 +0200, Bernd Helmle wrote:

Hmm, seems it stumbles while reading client_encoding....

This is probably similar to what I had a couple weeks ago. With today's
new minor releases, I get:

$ psql
psql: invalid connection option "client_encoding"

(I was getting another message before)

This is 9.1's psql connecting to 9.1's server. For some reason, psql
uses 9.0 client libs, so if I export LD_LIBRARY_PATH, everything works:

$ LD_LIBRARY_PATH=/usr/pgsql-9.1/lib psql
...

Could it be the same thing?
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

#6Bernd Helmle
mailings@oopsware.de
In reply to: Bernd Helmle (#3)
Re: JDBC connections to 9.1

--On 18. April 2011 16:17:57 +0200 Bernd Helmle <mailings@oopsware.de> wrote:

16:09:47.942 (1) <=BE ParameterStatus(client_encoding = UTF8)
org.postgresql.util.PSQLException: Protocol error. Session setup failed.
at
org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFa
ctoryImpl.java:498)

ConnectionFactoryImpl.readStartupMessages() has this:

else if (name.equals("client_encoding"))

{

if (!value.equals("UNICODE"))

throw new PSQLException(GT.tr("Protocol error. Session
setup failed."), PSQLState.PROTOCOL_VIOLATION);

pgStream.setEncoding(Encoding.getDatabaseEncoding("UNICODE"));

}

If i am reading it correct, it reads "UTF8" from the backend, while expecting
"UNICODE" only. Not sure what change has caused this, though. If i extend the
check to include "UTF8", everything seems to work.

--
Thanks

Bernd

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bernd Helmle (#6)
Re: JDBC connections to 9.1

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

#8Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#7)
Re: JDBC connections to 9.1

On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

Ouch. I hate to revert that, since it seems like a clear improvement.
But I also hate to break JDBC. Ouch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#9Dave Cramer
pg@fastcrypt.com
In reply to: Tom Lane (#7)
Re: [JDBC] JDBC connections to 9.1

On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

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

#10Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Tom Lane (#7)
Re: JDBC connections to 9.1

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

#11Mike Fowler
mike@mlfowler.com
In reply to: Tom Lane (#7)
Re: [JDBC] JDBC connections to 9.1

On 18/04/11 15:57, Tom Lane wrote:

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

Am I right in thinking that would be that change committed on the 7th
(http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ?
I've just run the JDBC test build on my machine and it fails dismally
with this very message repeated over and over again. What concerns me
most is that (assuming my dates are right) the JDBC driver has been
broken for 11 days and no one noticed. This would lead me to believe
that there is no JDBC build server. What would it take to set one up? If
someone can point me to a test machine I'd happily assist in setting one up.

As for the breakage itself I'm OK with a new driver version for a new
database version and from my experience people expect that. I recall a
number of people asking me if an 8.4 driver would be OK to use against 9
before the 9 version was stable.

Regards,

--
Mike Fowler
Registered Linux user: 379787

#12Dave Cramer
pg@fastcrypt.com
In reply to: Mike Fowler (#11)
Re: [JDBC] JDBC connections to 9.1

On Mon, Apr 18, 2011 at 11:14 AM, Mike Fowler <mike@mlfowler.com> wrote:

On 18/04/11 15:57, Tom Lane wrote:

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

Am I right in thinking that would be that change committed on the 7th
(http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ?
I've just run the JDBC test build on my machine and it fails dismally with
this very message repeated over and over again. What concerns me most is
that (assuming my dates are right) the JDBC driver has been broken for 11
days and no one noticed. This would lead me to believe that there is no JDBC
build server. What would it take to set one up? If someone can point me to a
test machine I'd happily assist in setting one up.

As for the breakage itself I'm OK with a new driver version for a new
database version and from my experience people expect that. I recall a
number of people asking me if an 8.4 driver would be OK to use against 9
before the 9 version was stable.

Regards,

One would need a machine which supports java 1.4, 1.5, and 1.6 since
the driver builds all 3 versions. There's actually a 4th between 1.4
and 1.5 but I don't recall the specifics

Dave

Show quoted text

--
Mike Fowler
Registered Linux user: 379787

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

#13Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dave Cramer (#9)
Re: [JDBC] JDBC connections to 9.1

Dave Cramer <pg@fastcrypt.com> writes:

On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

Older drivers will fail for sure. We can fix newer drivers, but if we
leave it we will see a slew of bug reports.

Yeah. I'm thinking what we should do here is revert the change, with a
note in the source about why, and also change the JDBC driver to send
and expect "UTF8" not "UNICODE" (which as Kevin says is more correct
anyway). Then in a few releases' time we can un-revert the server
change.

regards, tom lane

#14Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mike Fowler (#11)
Re: [JDBC] JDBC connections to 9.1

Mike Fowler <mike@mlfowler.com> writes:

On 18/04/11 15:57, Tom Lane wrote:

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:

Am I right in thinking that would be that change committed on the 7th
(http://archives.postgresql.org/pgsql-committers/2011-04/msg00039.php) ?

Yes, that one.

What concerns me
most is that (assuming my dates are right) the JDBC driver has been
broken for 11 days and no one noticed. This would lead me to believe
that there is no JDBC build server. What would it take to set one up?

+1 for doing something along that line.

regards, tom lane

#15Dave Cramer
pg@fastcrypt.com
In reply to: Tom Lane (#13)
Re: [JDBC] JDBC connections to 9.1

On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Cramer <pg@fastcrypt.com> writes:

On Mon, Apr 18, 2011 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

Older drivers will fail for sure. We can fix newer drivers, but if we
leave it we will see a slew of bug reports.

Yeah.  I'm thinking what we should do here is revert the change, with a
note in the source about why, and also change the JDBC driver to send
and expect "UTF8" not "UNICODE" (which as Kevin says is more correct
anyway).  Then in a few releases' time we can un-revert the server
change.

Well initially my concern was that people would have a challenge in
the case where they had to re-certify their application if we made
this change, however I realize they will have to do this anyway since
upgrading to 9.1 is what necessitates it.

So I'm less concerned with bug reports since people can just upgrade both

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

#16Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dave Cramer (#15)
Re: [JDBC] JDBC connections to 9.1

Dave Cramer <pg@fastcrypt.com> writes:

On Mon, Apr 18, 2011 at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Yeah. I'm thinking what we should do here is revert the change, with a
note in the source about why, and also change the JDBC driver to send
and expect "UTF8" not "UNICODE" (which as Kevin says is more correct
anyway). Then in a few releases' time we can un-revert the server
change.

Well initially my concern was that people would have a challenge in
the case where they had to re-certify their application if we made
this change, however I realize they will have to do this anyway since
upgrading to 9.1 is what necessitates it.

I don't see any backwards compatibility risk, if that's what you mean.
Every backend release since 7.3 has treated client_encoding 'UTF8' and
'UNICODE' the same, and earlier releases didn't accept either one.

regards, tom lane

#17Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#14)
Re: [JDBC] JDBC connections to 9.1

On 04/18/2011 11:25 AM, Tom Lane wrote:

What concerns me most is that (assuming my dates are right) the JDBC driver has been
broken for 11 days and no one noticed. This would lead me to believe
that there is no JDBC build server. What would it take to set one up?

+1 for doing something along that line.

All you'd need to do is write a step for a buildfarm animal to fetch the
JDBC driver and run some tests, and run it in a buildfarm client
somewhere. The server code is quite agnostic about the steps that are
reported on.

IOW in addition to a running buildfarm member you need to write a small
amount (< 100 lines, possibly much less) of perl code.

cheers

andrew

#18Mike Fowler
mike@mlfowler.com
In reply to: Andrew Dunstan (#17)
Re: [JDBC] JDBC connections to 9.1

On 18/04/11 17:35, Andrew Dunstan wrote:

On 04/18/2011 11:25 AM, Tom Lane wrote:

What concerns me most is that (assuming my dates are right) the
JDBC driver has been
broken for 11 days and no one noticed. This would lead me to believe
that there is no JDBC build server. What would it take to set one up?

+1 for doing something along that line.

All you'd need to do is write a step for a buildfarm animal to fetch
the JDBC driver and run some tests, and run it in a buildfarm client
somewhere. The server code is quite agnostic about the steps that are
reported on.

IOW in addition to a running buildfarm member you need to write a
small amount (< 100 lines, possibly much less) of perl code.

cheers

andrew

I've found the entry on the Developer Wiki
(http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto). What I'll
do is set-up three "farms" on my machine - one for 1.4, one for 1.5 and
one for 1.6. It's been a while since I've had an excuse to write some
Perl! I can't guarantee when I'll have it done as I'm away for a little
over a week from Wednesday and I'm not allowed internet access!

Regards,

--
Mike Fowler
Registered Linux user: 379787

#19Mike Fowler
mike@mlfowler.com
In reply to: Tom Lane (#16)
1 attachment(s)
Re: [JDBC] JDBC connections to 9.1

On 18/04/11 17:12, Tom Lane wrote:

Dave Cramer<pg@fastcrypt.com> writes:

Well initially my concern was that people would have a challenge in
the case where they had to re-certify their application if we made
this change, however I realize they will have to do this anyway since
upgrading to 9.1 is what necessitates it.

I don't see any backwards compatibility risk, if that's what you mean.
Every backend release since 7.3 has treated client_encoding 'UTF8' and
'UNICODE' the same, and earlier releases didn't accept either one.

regards, tom lane

As there seems to be a consensus forming for fixing the JDBC driver,
I've taken the liberty do so at the risk of being shot down. The patch
is fairly straightforward, just changing UNICODE to UTF8 in a number of
files including the translation files. I've tested this against 9.1devel
(HEAD) and 8.4.7. For each database version I build and the tests
running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit.

Regards,

--
Mike Fowler
Registered Linux user: 379787

Attachments:

unicode-utf8-jdbc.patchtext/x-diff; name=unicode-utf8-jdbc.patchDownload
Index: doc/pgjdbc.xml
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/doc/pgjdbc.xml,v
retrieving revision 1.40
diff -c -r1.40 pgjdbc.xml
*** doc/pgjdbc.xml	25 Dec 2010 07:07:44 -0000	1.40
--- doc/pgjdbc.xml	18 Apr 2011 16:32:49 -0000
***************
*** 179,185 ****
      encoding and you will have problems the moment you store data in it that
      does not fit in the seven bit <acronym>ASCII</acronym> character set.
      If you do not know what your encoding will be or are otherwise unsure
!     about what you will be storing the <literal>UNICODE</literal> encoding
      is a reasonable default to use.
     </para>
    </sect1>
--- 179,185 ----
      encoding and you will have problems the moment you store data in it that
      does not fit in the seven bit <acronym>ASCII</acronym> character set.
      If you do not know what your encoding will be or are otherwise unsure
!     about what you will be storing the <literal>UTF8</literal> encoding
      is a reasonable default to use.
     </para>
    </sect1>
Index: org/postgresql/core/BaseConnection.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/BaseConnection.java,v
retrieving revision 1.23
diff -c -r1.23 BaseConnection.java
*** org/postgresql/core/BaseConnection.java	1 May 2010 14:40:51 -0000	1.23
--- org/postgresql/core/BaseConnection.java	18 Apr 2011 16:32:49 -0000
***************
*** 96,102 ****
  
      /**
       * Encode a string using the database's client_encoding
!      * (usually UNICODE, but can vary on older server versions).
       * This is used when constructing synthetic resultsets (for
       * example, in metadata methods).
       *
--- 96,102 ----
  
      /**
       * Encode a string using the database's client_encoding
!      * (usually UTF8, but can vary on older server versions).
       * This is used when constructing synthetic resultsets (for
       * example, in metadata methods).
       *
Index: org/postgresql/core/v2/ConnectionFactoryImpl.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v2/ConnectionFactoryImpl.java,v
retrieving revision 1.21
diff -c -r1.21 ConnectionFactoryImpl.java
*** org/postgresql/core/v2/ConnectionFactoryImpl.java	31 Mar 2011 03:06:38 -0000	1.21
--- org/postgresql/core/v2/ConnectionFactoryImpl.java	18 Apr 2011 16:32:49 -0000
***************
*** 380,388 ****
              // 7.3 server that defaults to autocommit = off.
  
              if (logger.logDebug())
!                 logger.debug("Switching to UNICODE client_encoding");
  
!             String sql = "begin; set autocommit = on; set client_encoding = 'UNICODE'; ";
              if (dbVersion.compareTo("9.0") >= 0) {
                  sql += "SET extra_float_digits=3; ";
              } else if (dbVersion.compareTo("7.4") >= 0) {
--- 380,388 ----
              // 7.3 server that defaults to autocommit = off.
  
              if (logger.logDebug())
!                 logger.debug("Switching to UTF8 client_encoding");
  
!             String sql = "begin; set autocommit = on; set client_encoding = 'UTF8'; ";
              if (dbVersion.compareTo("9.0") >= 0) {
                  sql += "SET extra_float_digits=3; ";
              } else if (dbVersion.compareTo("7.4") >= 0) {
***************
*** 391,397 ****
              sql += "commit";
  
              SetupQueryRunner.run(protoConnection, sql, false);
!             protoConnection.setEncoding(Encoding.getDatabaseEncoding("UNICODE"));
          }
          else
          {
--- 391,397 ----
              sql += "commit";
  
              SetupQueryRunner.run(protoConnection, sql, false);
!             protoConnection.setEncoding(Encoding.getDatabaseEncoding("UTF8"));
          }
          else
          {
Index: org/postgresql/core/v3/ConnectionFactoryImpl.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v3/ConnectionFactoryImpl.java,v
retrieving revision 1.24
diff -c -r1.24 ConnectionFactoryImpl.java
*** org/postgresql/core/v3/ConnectionFactoryImpl.java	31 Mar 2011 03:06:39 -0000	1.24
--- org/postgresql/core/v3/ConnectionFactoryImpl.java	18 Apr 2011 16:32:49 -0000
***************
*** 97,103 ****
              String[][] params = {
                                      { "user", user },
                                      { "database", database },
!                                     { "client_encoding", "UNICODE" },
                                      { "DateStyle", "ISO" },
                                      { "extra_float_digits", "2" }
                                  };
--- 97,103 ----
              String[][] params = {
                                      { "user", user },
                                      { "database", database },
!                                     { "client_encoding", "UTF8" },
                                      { "DateStyle", "ISO" },
                                      { "extra_float_digits", "2" }
                                  };
***************
*** 494,502 ****
                      protoConnection.setServerVersion(value);
                  else if (name.equals("client_encoding"))
                  {
!                     if (!value.equals("UNICODE"))
                          throw new PSQLException(GT.tr("Protocol error.  Session setup failed."), PSQLState.PROTOCOL_VIOLATION);
!                     pgStream.setEncoding(Encoding.getDatabaseEncoding("UNICODE"));
                  }
                  else if (name.equals("standard_conforming_strings"))
                  {
--- 494,502 ----
                      protoConnection.setServerVersion(value);
                  else if (name.equals("client_encoding"))
                  {
!                     if (!value.equals("UTF8"))
                          throw new PSQLException(GT.tr("Protocol error.  Session setup failed."), PSQLState.PROTOCOL_VIOLATION);
!                     pgStream.setEncoding(Encoding.getDatabaseEncoding("UTF8"));
                  }
                  else if (name.equals("standard_conforming_strings"))
                  {
Index: org/postgresql/core/v3/QueryExecutorImpl.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v3/QueryExecutorImpl.java,v
retrieving revision 1.52
diff -c -r1.52 QueryExecutorImpl.java
*** org/postgresql/core/v3/QueryExecutorImpl.java	2 Apr 2011 08:29:57 -0000	1.52
--- org/postgresql/core/v3/QueryExecutorImpl.java	18 Apr 2011 16:32:50 -0000
***************
*** 1869,1878 ****
                      if (logger.logDebug())
                          logger.debug(" <=BE ParameterStatus(" + name + " = " + value + ")");
  
!                     if (name.equals("client_encoding") && !(value.equalsIgnoreCase("UNICODE") || value.equalsIgnoreCase("UTF8")) && !allowEncodingChanges)
                      {
                          protoConnection.close(); // we're screwed now; we can't trust any subsequent string.
!                         handler.handleError(new PSQLException(GT.tr("The server''s client_encoding parameter was changed to {0}. The JDBC driver requires client_encoding to be UNICODE for correct operation.", value), PSQLState.CONNECTION_FAILURE));
                          endQuery = true;
                      }
  
--- 1869,1878 ----
                      if (logger.logDebug())
                          logger.debug(" <=BE ParameterStatus(" + name + " = " + value + ")");
  
!                     if (name.equals("client_encoding") && !value.equalsIgnoreCase("UTF8") && !allowEncodingChanges)
                      {
                          protoConnection.close(); // we're screwed now; we can't trust any subsequent string.
!                         handler.handleError(new PSQLException(GT.tr("The server''s client_encoding parameter was changed to {0}. The JDBC driver requires client_encoding to be UTF8 for correct operation.", value), PSQLState.CONNECTION_FAILURE));
                          endQuery = true;
                      }
  
Index: org/postgresql/jdbc3/AbstractJdbc3Statement.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/jdbc3/AbstractJdbc3Statement.java,v
retrieving revision 1.24
diff -c -r1.24 AbstractJdbc3Statement.java
*** org/postgresql/jdbc3/AbstractJdbc3Statement.java	28 Jan 2009 09:50:21 -0000	1.24
--- org/postgresql/jdbc3/AbstractJdbc3Statement.java	18 Apr 2011 16:32:50 -0000
***************
*** 936,946 ****
      /**
       * Sets the designated parameter to the given <code>Reader</code>
       * object, which is the given number of characters long.
!      * When a very large UNICODE value is input to a <code>LONGVARCHAR</code>
       * parameter, it may be more practical to send it via a
       * <code>java.io.Reader</code> object. The data will be read from the stream
       * as needed until end-of-file is reached. The JDBC driver will
!      * do any necessary conversion from UNICODE to the database char format.
       *
       * <P><B>Note:</B> This stream object can either be a standard
       * Java stream object or your own subclass that implements the
--- 936,946 ----
      /**
       * Sets the designated parameter to the given <code>Reader</code>
       * object, which is the given number of characters long.
!      * When a very large UTF8 value is input to a <code>LONGVARCHAR</code>
       * parameter, it may be more practical to send it via a
       * <code>java.io.Reader</code> object. The data will be read from the stream
       * as needed until end-of-file is reached. The JDBC driver will
!      * do any necessary conversion from UTF8 to the database char format.
       *
       * <P><B>Note:</B> This stream object can either be a standard
       * Java stream object or your own subclass that implements the
***************
*** 948,954 ****
       *
       * @param parameterName the name of the parameter
       * @param reader the <code>java.io.Reader</code> object that
!      *    contains the UNICODE data used as the designated parameter
       * @param length the number of characters in the stream
       * @exception SQLException if a database access error occurs
       * @since 1.4
--- 948,954 ----
       *
       * @param parameterName the name of the parameter
       * @param reader the <code>java.io.Reader</code> object that
!      *    contains the UTF8 data used as the designated parameter
       * @param length the number of characters in the stream
       * @exception SQLException if a database access error occurs
       * @since 1.4
Index: org/postgresql/test/jdbc2/DatabaseEncodingTest.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/test/jdbc2/DatabaseEncodingTest.java,v
retrieving revision 1.8
diff -c -r1.8 DatabaseEncodingTest.java
*** org/postgresql/test/jdbc2/DatabaseEncodingTest.java	8 Jan 2008 06:56:30 -0000	1.8
--- org/postgresql/test/jdbc2/DatabaseEncodingTest.java	18 Apr 2011 16:32:50 -0000
***************
*** 70,86 ****
      }
  
      public void testEncoding() throws Exception {
!         // Check that we have a UNICODE server encoding, or we must skip this test.
          Statement stmt = con.createStatement();
          ResultSet rs = stmt.executeQuery("SELECT getdatabaseencoding()");
          assertTrue(rs.next());
  
          String dbEncoding = rs.getString(1);
!         if (!dbEncoding.equals("UNICODE") && !dbEncoding.equals("UTF8"))
          {
!             System.err.println("DatabaseEncodingTest: Skipping UNICODE database tests as test database encoding is " + dbEncoding);
              rs.close();
!             return ; // not a UNICODE database.
          }
  
          rs.close();
--- 70,86 ----
      }
  
      public void testEncoding() throws Exception {
!         // Check that we have a UTF8 server encoding, or we must skip this test.
          Statement stmt = con.createStatement();
          ResultSet rs = stmt.executeQuery("SELECT getdatabaseencoding()");
          assertTrue(rs.next());
  
          String dbEncoding = rs.getString(1);
!         if (!dbEncoding.equals("UTF8"))
          {
!             System.err.println("DatabaseEncodingTest: Skipping UTF8 database tests as test database encoding is " + dbEncoding);
              rs.close();
!             return ; // not a UTF8 database.
          }
  
          rs.close();
Index: org/postgresql/test/jdbc2/EncodingTest.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/test/jdbc2/EncodingTest.java,v
retrieving revision 1.11
diff -c -r1.11 EncodingTest.java
*** org/postgresql/test/jdbc2/EncodingTest.java	19 Feb 2008 06:12:24 -0000	1.11
--- org/postgresql/test/jdbc2/EncodingTest.java	18 Apr 2011 16:32:50 -0000
***************
*** 32,38 ****
      public void testCreation() throws Exception
      {
          Encoding encoding;
!         encoding = Encoding.getDatabaseEncoding("UNICODE");
          assertEquals("UTF", encoding.name().substring(0, 3).toUpperCase(Locale.US));
          encoding = Encoding.getDatabaseEncoding("SQL_ASCII");
          assertTrue(encoding.name().toUpperCase(Locale.US).indexOf("ASCII") != -1);
--- 32,38 ----
      public void testCreation() throws Exception
      {
          Encoding encoding;
!         encoding = Encoding.getDatabaseEncoding("UTF8");
          assertEquals("UTF", encoding.name().substring(0, 3).toUpperCase(Locale.US));
          encoding = Encoding.getDatabaseEncoding("SQL_ASCII");
          assertTrue(encoding.name().toUpperCase(Locale.US).indexOf("ASCII") != -1);
***************
*** 43,49 ****
  
      public void testTransformations() throws Exception
      {
!         Encoding encoding = Encoding.getDatabaseEncoding("UNICODE");
          assertEquals("ab", encoding.decode(new byte[] { 97, 98 }));
  
          assertEquals(2, encoding.encode("ab").length);
--- 43,49 ----
  
      public void testTransformations() throws Exception
      {
!         Encoding encoding = Encoding.getDatabaseEncoding("UTF8");
          assertEquals("ab", encoding.decode(new byte[] { 97, 98 }));
  
          assertEquals(2, encoding.encode("ab").length);
Index: org/postgresql/translation/bg.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/bg.po,v
retrieving revision 1.1
diff -c -r1.1 bg.po
*** org/postgresql/translation/bg.po	28 Dec 2009 22:14:21 -0000	1.1
--- org/postgresql/translation/bg.po	18 Apr 2011 16:32:50 -0000
***************
*** 420,429 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "Параметърът client_encoding при сървъра бе променен на {0}. JDBC драйвъра "
! "изисква client_encoding да бъде UNICODE за да функционира правилно."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1856
  #, java-format
--- 420,429 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "Параметърът client_encoding при сървъра бе променен на {0}. JDBC драйвъра "
! "изисква client_encoding да бъде UTF8 за да функционира правилно."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1856
  #, java-format
Index: org/postgresql/translation/cs.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/cs.po,v
retrieving revision 1.2
diff -c -r1.2 cs.po
*** org/postgresql/translation/cs.po	22 Aug 2005 05:51:40 -0000	1.2
--- org/postgresql/translation/cs.po	18 Apr 2011 16:32:50 -0000
***************
*** 254,260 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1330
--- 254,260 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1330
Index: org/postgresql/translation/de.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/de.po,v
retrieving revision 1.10
diff -c -r1.10 de.po
*** org/postgresql/translation/de.po	19 Sep 2008 00:01:02 -0000	1.10
--- org/postgresql/translation/de.po	18 Apr 2011 16:32:51 -0000
***************
*** 303,312 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "Der Parameter ''client_encoding'' wurde auf dem Server auf {0} verändert. "
! "Der JDBC-Treiber setzt für korrektes Funktionieren die Einstellung UNICODE "
  "voraus."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
--- 303,312 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "Der Parameter ''client_encoding'' wurde auf dem Server auf {0} verändert. "
! "Der JDBC-Treiber setzt für korrektes Funktionieren die Einstellung UTF8 "
  "voraus."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
Index: org/postgresql/translation/es.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/es.po,v
retrieving revision 1.2
diff -c -r1.2 es.po
*** org/postgresql/translation/es.po	7 Nov 2004 22:17:10 -0000	1.2
--- org/postgresql/translation/es.po	18 Apr 2011 16:32:51 -0000
***************
*** 186,192 ****
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1028
  msgid ""
  "The server's client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1034
--- 186,192 ----
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1028
  msgid ""
  "The server's client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1034
Index: org/postgresql/translation/fr.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/fr.po,v
retrieving revision 1.8
diff -c -r1.8 fr.po
*** org/postgresql/translation/fr.po	27 Jul 2007 22:13:09 -0000	1.8
--- org/postgresql/translation/fr.po	18 Apr 2011 16:32:52 -0000
***************
*** 294,303 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "Le paramètre client_encoding du serveur a été changé pour {0}. Le pilote "
! "JDBC nécessite l''affectation de la valeur UNICODE à client_encoding pour un "
  "fonctionnement correct."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1361
--- 294,303 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "Le paramètre client_encoding du serveur a été changé pour {0}. Le pilote "
! "JDBC nécessite l''affectation de la valeur UTF8 à client_encoding pour un "
  "fonctionnement correct."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1361
Index: org/postgresql/translation/it.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/it.po,v
retrieving revision 1.6
diff -c -r1.6 it.po
*** org/postgresql/translation/it.po	29 Jun 2006 23:29:39 -0000	1.6
--- org/postgresql/translation/it.po	18 Apr 2011 16:32:52 -0000
***************
*** 290,299 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "Il parametro «client_encoding» del server è stato cambiato in {0}. Il driver "
! "JDBC richiede che «client_encoding» sia UNICODE per un corretto "
  "funzionamento."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1357
--- 290,299 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "Il parametro «client_encoding» del server è stato cambiato in {0}. Il driver "
! "JDBC richiede che «client_encoding» sia UTF8 per un corretto "
  "funzionamento."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1357
Index: org/postgresql/translation/ja.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/ja.po,v
retrieving revision 1.2
diff -c -r1.2 ja.po
*** org/postgresql/translation/ja.po	5 May 2010 20:51:57 -0000	1.2
--- org/postgresql/translation/ja.po	18 Apr 2011 16:32:52 -0000
***************
*** 413,422 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "サーバーのclient_encodingパラメーターが {0} に変わりました、JDBCドライバー"
! "は、正しい操作のためclient_encodingをUNICODEにすることを要求します。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1856
  #, java-format
--- 413,422 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "サーバーのclient_encodingパラメーターが {0} に変わりました、JDBCドライバー"
! "は、正しい操作のためclient_encodingをUTF8にすることを要求します。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1856
  #, java-format
Index: org/postgresql/translation/nl.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/nl.po,v
retrieving revision 1.2
diff -c -r1.2 nl.po
*** org/postgresql/translation/nl.po	7 Nov 2004 22:17:10 -0000	1.2
--- org/postgresql/translation/nl.po	18 Apr 2011 16:32:52 -0000
***************
*** 167,173 ****
  #: org/postgresql/core/v3/QueryExecutorImpl.java:980
  msgid ""
  "The server's client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:986
--- 167,173 ----
  #: org/postgresql/core/v3/QueryExecutorImpl.java:980
  msgid ""
  "The server's client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:986
Index: org/postgresql/translation/pl.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/pl.po,v
retrieving revision 1.3
diff -c -r1.3 pl.po
*** org/postgresql/translation/pl.po	25 May 2005 06:09:26 -0000	1.3
--- org/postgresql/translation/pl.po	18 Apr 2011 16:32:52 -0000
***************
*** 216,222 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1330
--- 216,222 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1330
Index: org/postgresql/translation/pt_BR.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/pt_BR.po,v
retrieving revision 1.16
diff -c -r1.16 pt_BR.po
*** org/postgresql/translation/pt_BR.po	1 Jun 2009 23:40:46 -0000	1.16
--- org/postgresql/translation/pt_BR.po	18 Apr 2011 16:32:53 -0000
***************
*** 292,301 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "O parâmetro do servidor client_encoding foi alterado para {0}. O driver JDBC "
! "requer que o client_encoding seja UNICODE para operação normal."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
  #, java-format
--- 292,301 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "O parâmetro do servidor client_encoding foi alterado para {0}. O driver JDBC "
! "requer que o client_encoding seja UTF8 para operação normal."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
  #, java-format
Index: org/postgresql/translation/ru.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/ru.po,v
retrieving revision 1.6
diff -c -r1.6 ru.po
*** org/postgresql/translation/ru.po	22 May 2006 07:15:23 -0000	1.6
--- org/postgresql/translation/ru.po	18 Apr 2011 16:32:53 -0000
***************
*** 297,303 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1357
--- 297,303 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1357
Index: org/postgresql/translation/sr.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/sr.po,v
retrieving revision 1.3
diff -c -r1.3 sr.po
*** org/postgresql/translation/sr.po	1 Jun 2009 23:39:32 -0000	1.3
--- org/postgresql/translation/sr.po	18 Apr 2011 16:32:53 -0000
***************
*** 289,298 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "Serverov client_encoding parametar je promenjen u  {0}.JDBC darajver zahteva "
! "UNICODE client_encoding  za uspešno izvršavanje operacije."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
  #, java-format
--- 289,298 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "Serverov client_encoding parametar je promenjen u  {0}.JDBC darajver zahteva "
! "UTF8 client_encoding  za uspešno izvršavanje operacije."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
  #, java-format
Index: org/postgresql/translation/tr.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/tr.po,v
retrieving revision 1.10
diff -c -r1.10 tr.po
*** org/postgresql/translation/tr.po	2 Jun 2009 00:04:00 -0000	1.10
--- org/postgresql/translation/tr.po	18 Apr 2011 16:32:53 -0000
***************
*** 286,295 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "İstemcinin client_encoding parametresi {0} değerine değiştirilmiştir. JDBC "
! "sürücüsünün doğru çalışması için client_encoding parameteresinin UNICODE "
  "olması gerekir."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
--- 286,295 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "İstemcinin client_encoding parametresi {0} değerine değiştirilmiştir. JDBC "
! "sürücüsünün doğru çalışması için client_encoding parameteresinin UTF8 "
  "olması gerekir."
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1426
Index: org/postgresql/translation/zh_CN.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/zh_CN.po,v
retrieving revision 1.2
diff -c -r1.2 zh_CN.po
*** org/postgresql/translation/zh_CN.po	31 Jan 2008 08:58:24 -0000	1.2
--- org/postgresql/translation/zh_CN.po	18 Apr 2011 16:32:54 -0000
***************
*** 275,284 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "这服务器的 client_encoding 参数被改成 {0},JDBC 驱动程序请求需要 "
! "client_encoding 为 UNICODE 以正确工作。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
  #, java-format
--- 275,284 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "这服务器的 client_encoding 参数被改成 {0},JDBC 驱动程序请求需要 "
! "client_encoding 为 UTF8 以正确工作。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
  #, java-format
Index: org/postgresql/translation/zh_TW.po
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/translation/zh_TW.po,v
retrieving revision 1.4
diff -c -r1.4 zh_TW.po
*** org/postgresql/translation/zh_TW.po	30 Jan 2008 09:16:48 -0000	1.4
--- org/postgresql/translation/zh_TW.po	18 Apr 2011 16:32:54 -0000
***************
*** 275,284 ****
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UNICODE for correct operation."
  msgstr ""
  "這伺服器的 client_encoding 參數被改成 {0},JDBC 驅動程式請求需要 "
! "client_encoding 為 UNICODE 以正確工作。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
  #, java-format
--- 275,284 ----
  #, java-format
  msgid ""
  "The server''s client_encoding parameter was changed to {0}. The JDBC driver "
! "requires client_encoding to be UTF8 for correct operation."
  msgstr ""
  "這伺服器的 client_encoding 參數被改成 {0},JDBC 驅動程式請求需要 "
! "client_encoding 為 UTF8 以正確工作。"
  
  #: org/postgresql/core/v3/QueryExecutorImpl.java:1373
  #, java-format
#20Kris Jurka
books@ejurka.com
In reply to: Mike Fowler (#19)
Re: [JDBC] JDBC connections to 9.1

On Mon, 18 Apr 2011, Mike Fowler wrote:

On 18/04/11 17:12, Tom Lane wrote:

Dave Cramer<pg@fastcrypt.com> writes:

Well initially my concern was that people would have a challenge in
the case where they had to re-certify their application if we made
this change, however I realize they will have to do this anyway since
upgrading to 9.1 is what necessitates it.

I don't see any backwards compatibility risk, if that's what you mean.
Every backend release since 7.3 has treated client_encoding 'UTF8' and
'UNICODE' the same, and earlier releases didn't accept either one.

regards, tom lane

As there seems to be a consensus forming for fixing the JDBC driver, I've
taken the liberty do so at the risk of being shot down. The patch is fairly
straightforward, just changing UNICODE to UTF8 in a number of files including
the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7.
For each database version I build and the tests running JDKs 1.4.2_19,
1.5.0_22 and 1.6.0_2. All on 32-bit.

Thanks, applied, mostly. It's great to have a patch for a problem before
you even know it exists.

I didn't modify the .po files. I doubt this will change the adjacent
translation wording, but directly patching .po files is only something to
do in more dire circumstances (like needing to make a backpatch to an old
branch that won't get translators to look at it before the next release.)

I also discarded your changes to AbstractJdbc3Statement. Those Unicode
mentions are from the interface Javadoc, so I left them alone.

Kris Jurka

#21Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kris Jurka (#20)
Re: [JDBC] JDBC connections to 9.1

Kris Jurka <books@ejurka.com> writes:

On Mon, 18 Apr 2011, Mike Fowler wrote:

As there seems to be a consensus forming for fixing the JDBC driver, I've
taken the liberty do so at the risk of being shot down. The patch is fairly
straightforward, just changing UNICODE to UTF8 in a number of files including
the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7.
For each database version I build and the tests running JDKs 1.4.2_19,
1.5.0_22 and 1.6.0_2. All on 32-bit.

Thanks, applied, mostly. It's great to have a patch for a problem before
you even know it exists.

For purposes of the notes in the server-side fix, could you state which
JDBC driver versions these changes will first appear in?

regards, tom lane

#22Kris Jurka
books@ejurka.com
In reply to: Tom Lane (#21)
Re: [JDBC] JDBC connections to 9.1

On Tue, 19 Apr 2011, Tom Lane wrote:

Kris Jurka <books@ejurka.com> writes:

On Mon, 18 Apr 2011, Mike Fowler wrote:

As there seems to be a consensus forming for fixing the JDBC driver, I've
taken the liberty do so at the risk of being shot down. The patch is fairly
straightforward, just changing UNICODE to UTF8 in a number of files including
the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7.
For each database version I build and the tests running JDKs 1.4.2_19,
1.5.0_22 and 1.6.0_2. All on 32-bit.

Thanks, applied, mostly. It's great to have a patch for a problem before
you even know it exists.

For purposes of the notes in the server-side fix, could you state which
JDBC driver versions these changes will first appear in?

This is in 9.1dev-900 and won't be backpatched.

http://jdbc.postgresql.org/download.html#development

Kris Jurka

#23Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kris Jurka (#22)
Re: [JDBC] JDBC connections to 9.1

Kris Jurka <books@ejurka.com> writes:

On Tue, 19 Apr 2011, Tom Lane wrote:

For purposes of the notes in the server-side fix, could you state which
JDBC driver versions these changes will first appear in?

This is in 9.1dev-900 and won't be backpatched.

OK, thanks. I've committed a patch to keep the server from
canonicalizing a setting of "UNICODE" (but not any other variations).
That should keep older drivers from breaking, and in a few years we
can remove the kluge, if anyone bothers ...

regards, tom lane