getBinaryStream/setBinaryStream 7.2<->7.4 Question

Hi,

I just upgraded from postgres 7.2 to 7.4 (pg72jdbc2.jar to
pg74.1jdbc3.jar), after the upgrade I got some behaviour I simpy dont
understand.

For example: given the following code:
Table Bild is (int, int, bytea)

void test(Connection con) {
PreparedStatement stmt=null;
try {
stmt=con.prepareStatement("insert into Bild (bildid, filmid,
daten) values(?,?,?)");
stmt.setInt(1,100000);
stmt.setInt(2,10001);
stmt.setBinaryStream(3,new ByteArrayInputStream(new
byte[]{(byte)255, (byte)216, (byte)255, (byte)224, (byte)0}), 5);
stmt.executeUpdate();
stmt.close();
stmt=con.prepareStatement("select daten from bild where
bildid=100000");
ResultSet rs = stmt.executeQuery();
if (rs.next()) {
InputStream in = rs.getBinaryStream(1);
int data;
while ( (data = in.read()) != -1)
System.out.println(data);
rs.close();
stmt.close();
}
stmt=con.prepareStatement("delete from bild where bildid=100000");
stmt.executeUpdate();
stmt.close();
}
catch (Exception e) {
e.printStackTrace();
}
}

output using pg72jdbc2.jar :
255
216
255
224
0

output using pg74.1jdbc3.jar :
195
191
195
152
195
191
195
160
0

in both cases the sequence 255,216,255,224,0 is stored in the database.
As you can see, values bigger than 127 are translated to 16bit values.
Is this the expected behaviour?

cu Harry

On Mon, 29 Dec 2003, Harry Schittler wrote:

> I just upgraded from postgres 7.2 to 7.4 (pg72jdbc2.jar to
> pg74.1jdbc3.jar), after the upgrade I got some behaviour I simpy dont
> understand.

I have not been able to duplicate this in a variety of configurations. I
suspect it may have something to do with the encoding used, but you have
not indicated your exact setup. You say you upgraded from 7.2 to 7.4, but
you only mention the JDBC driver, can you confirm that you upgraded the
server as well? Also what encodings are the 7.2 and 7.4 databases running
with? (You can get this from the \l command in psql.)

Kris Jurka

Hi,

Kris Jurka wrote:

>>I just upgraded from postgres 7.2 to 7.4 (pg72jdbc2.jar to
>>pg74.1jdbc3.jar), after the upgrade I got some behaviour I simpy dont
>>understand.
>>
>>
>I have not been able to duplicate this in a variety of configurations. I
>suspect it may have something to do with the encoding used, but you have
>not indicated your exact setup. You say you upgraded from 7.2 to 7.4, but
>you only mention the JDBC driver, can you confirm that you upgraded the
>server as well? Also what encodings are the 7.2 and 7.4 databases running
>with? (You can get this from the \l command in psql.)
>
>
Sorry, I upgraded both, the Server from 7.2 to 7.4 and the jdbc driver
as stated above.
The orginal setup was an 7.2 server with "latin1" encoding and the jdbc
driver with default options. After upgrading the Server and the jdbc
driver everything worked fine except for data retrieved via
getBinaryStream() or getBytes() from a "bytea "column. Setting the data
works ok (I verified this...). Changeing the client encoding with the
charset property didn't help, only switching back to the older driver
fixes the problem.
Barry Lind told me he thinks this is a known bug in the server, which
causing translation of bytea data to unicode. He suggested switching the
database to unicode. But I'm still a bit confused, about a serverbug
that goes away when changing the client?

cu Harry

On Mon, 29 Dec 2003, Harry Schittler wrote:

> Barry Lind told me he thinks this is a known bug in the server, which
> causing translation of bytea data to unicode. He suggested switching the
> database to unicode. But I'm still a bit confused, about a serverbug
> that goes away when changing the client?
>

Starting with the 7.3 server multibyte support came compiled in always, so
the JDBC driver started asking the server to do all conversion between
character sets and somewhere in there (the server conversion) is the bug.
The 7.2 JDBC driver doesn't know about this available functionality so it
doesn't come across the bug.

Kris Jurka