JDBC Encoding conversion bug - Mailing list pgsql-jdbc

From David Esposito
Subject JDBC Encoding conversion bug
Date
Msg-id 02bb01c37d25$b0f209a0$e101010a@lexlaptop
Whole thread Raw
List pgsql-jdbc

Hi,

 

I just upgraded my database to PG 7.3.4 from 7.2.1 yesterday ... However, I hit a pretty critical snag with the JDBC driver ... I have my DB encoding as SQL_ASCII and I have a significant amount of data that uses the full 8 bits (ñ, è, etc...) ... Prior to 7.3 and the new JDBC driver that comes with it (pg73jdbc2.jar), this data was not a problem ... However, I am now receiving the following whenever a column is retrieved that contains a high ASCII value character:

 

Invalid character data was found.  This is most likely caused by stored data containing characters that are invalid for the character set the database was created in.  The most common example of this is storing 8bit data in a SQL_ASCII database.

 

Now, I was under the assumption that ASCII is 8 bits ... At least, according to my little ASCII chart, there are 256 characters listed ... And the fact that the PG back-end supports 8 bit characters when the encoding is SQL_ASCII seems to confirm this ... So, in my opinion, this is a bug in the JDBC driver ... So what's up with this exception and error message?

 

Also, I have compiled the JDBC driver code from postgres-7.3.4.tar.gz and manually traced through it in my debugger ... The driver is hard-coded to use UTF-8 for PG 7.3 back ends ... It won't even honor the charSet parameter on the JDBC URL if I were to pass it .. Lines 373 to 376 of AbstractJdbc1Connection.java prove this ...

 

I am pretty stuck at this point ... What can I do? ... Recreating the database with a different encoding is _NOT_ an option ... the DB is over 5GB and takes over 4 hours to do a Backup/Restore .. I compiled PG 7.3.4 from source and didn't pass any flags to the configure script ... The back end is running on RedHat 7.1

 

Lastly, I'm running JDK 1.3.1 on my client machines ... I could potentially upgrade to JDK 1.4 but I'd prefer not to since it would require a fair amount of regression testing since this is a production application ..

 

Thanks in advance,

Dave

 

 

pgsql-jdbc by date:

Previous
From: "sc0698"
Date:
Subject: Re: rsetMetaData.getColumnCount();
Next
From: Luca Moscatelli
Date:
Subject: Re: Connection refused. HELP ME!!!!