Thread: JDBC support for CALL / PERFORM

I have some Java code that I'm trying to convert from Oracle to PG.
This code uses the JDBC batch functionality to submit batches of stored
procedures invocations using the "call" syntax.  I implemented the same
stored functions in PG, having them return void.  I converted the batch
statements to use "select" with these stored functions.  Even though the
stored functions return void, the select is still producing a result
set, and JDBC does not allow results with batches.

I'd like to take a crack at adding CALL (for Oracle and general JDBC
compatibility) and/or PERFORM (for PL/SQL compatibility) to the JDBC
driver.  My approach would be to simply substitute SELECT, then discard
the result set upon completion.

Is this approach feasible?  Is this change acceptable?

--
Guy Rouillier

On Mon, 13 Feb 2006, Guy Rouillier wrote:

> I have some Java code that I'm trying to convert from Oracle to PG.
> This code uses the JDBC batch functionality to submit batches of stored
> procedures invocations using the "call" syntax.  I implemented the same
> stored functions in PG, having them return void.  I converted the batch
> statements to use "select" with these stored functions.  Even though the
> stored functions return void, the select is still producing a result
> set, and JDBC does not allow results with batches.
>
> I'd like to take a crack at adding CALL (for Oracle and general JDBC
> compatibility) and/or PERFORM (for PL/SQL compatibility) to the JDBC
> driver.  My approach would be to simply substitute SELECT, then discard
> the result set upon completion.

You shouldn't need to do anything other than discard the results instead
of erroring for CallableStatement batches.  You shouldn't do any messing
with the SQL and CALL or PERFORM.  This should be handled by the standard
{call } syntax.

Also JDBC messages should go to the jdbc list, pgsql-jdbc@postgresql.org.

Kris Jurka