CallableStatement and getUpdateCount

From: Sam Lawrence <sam(at)fsbtech(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: CallableStatement and getUpdateCount
Date: 2008-03-31 15:29:11
Message-ID: 47F10347.6050403@fsbtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Hi,

I have a query about using CallableStatement with functions that return
a SETOF. I know the "Calling Stored Functions" documentation says use a
Statement or a PreparedStatement - I'm in the process of porting over a
database and would like to leave my calling code the same - that means
CallableStatement (more in a moment).

First, an example. A simple function (I know the SETOF is redundant in
this example, normally it wouldn't be) -

CREATE OR REPLACE FUNCTION cstest()
RETURNS SETOF integer AS
$$
SELECT 1;
$$
LANGUAGE 'sql' VOLATILE;

The calling code -

Class.forName("org.postgresql.Driver");
Connection con = DriverManager.getConnection("...");

CallableStatement cs = con.prepareCall("{call cstest()}");
cs.execute();

System.out.println("update count - should be -1? " +
cs.getUpdateCount());

ResultSet rs = cs.getResultSet();
while(rs.next())
{
System.out.println(rs.getInt(1));
}
rs.close();
cs.close();
con.close();

The code works fine and returns the record correctly. My problem is the
getUpdateCount after the execute - from the java.sql.Statement
documentation "if the result is a ResultSet object or there are no more
results, -1 is returned". It actually comes back as 1. Is this a bug or
have I missed something?

I found this problem via Spring's
org.springframework.jdbc.object.StoredProcedure class - it doesn't find
any ResultSets because it relies on the value of getUpdateCount.

I'm running PostgreSQL 8.3.0 with postgresql-8.3-603.jdbc4.

Thanks in advance.

Sam.

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2008-03-31 17:07:07 Re: Documentation problem with LargeObjectManager
Previous Message David Goodenough 2008-03-31 08:43:54 Re: Documentation problem with LargeObjectManager