Thread: 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