Boolean column stick to "false" after calling updateRow() on updateable ResultSet

From: Clemens Eisserer <linuxhippy(at)gmail(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Boolean column stick to "false" after calling updateRow() on updateable ResultSet
Date: 2020-01-25 16:43:02
Message-ID: CAFvQSYSMoYYJprnJhd2NjaDTE5wSxpY5N6xtVveBGGqZ35RpMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Hi,

I've observed something unexpected when migrating an application from
PostgreSQL-8.4.21 & postgresql-8.4-701.jdbc3.jar to PostgreSQL-12 &
postgresql-42.2.9.

With the updated software-stack boolean columns always seem to stick
to "false" after updateRow() is called on updateable ResultSets.
The value stored however is correct, and calling refreshRow() right
after updateRow() seems to restore the "old" behaviour and restores
the value set a few lines aboce.

I could fix the issue simply by forcing the additional roundtrip
caused by refreshRow - however I still wonder - is the observed
behaviour conformat to the spec / to be spected?

Thank you in advance & best regards, Clemens

//DDL
CREATE TABLE sometable (id integer NOT NULL, someprop boolean DEFAULT false);

//JDBC access
Statement st =
connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_UPDATABLE);
ResultSet rs = st.executeQuery("SELECT * FROM sometable WHERE id=...");
rs.next();
System.out.println(rs.getBoolean("someprop")); // value stored in DB
rs.updateBoolean("vereinsFlugzeug", true);
System.out.println(rs.getBoolean("someprop")); //Matches the
value set above (true)
rs.updateRow();
// rs.refreshRow(); //fetches the value stored
System.out.println(rs.getBoolean("someprop")); // always returns false.

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message PG Bug reporting form 2020-01-25 19:05:22 BUG #16230: Boolean column stick to "false" after calling updateRow() on updateable ResultSet
Previous Message Dave Cramer 2020-01-24 11:57:50 [pgjdbc/pgjdbc] 3dd5df: fix: actually use milliseconds instead of microsec...