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.
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... |