Skip site navigation (1) Skip section navigation (2)

Re: JDBC support for CALL / PERFORM

From: Kris Jurka <books(at)ejurka(dot)com>
To: Guy Rouillier <guyr(at)masergy(dot)com>
Cc: PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC support for CALL / PERFORM
Date: 2006-02-13 23:02:42
Message-ID: Pine.BSO.4.63.0602131759430.13231@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-interfacespgsql-jdbc

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(at)postgresql(dot)org(dot)

Kris Jurka

In response to

pgsql-interfaces by date

Next:From: Jeroen T. VermeulenDate: 2006-02-14 03:30:43
Subject: Re: Client libraries supporting pipelining
Previous:From: Guy RouillierDate: 2006-02-13 22:11:47
Subject: JDBC support for CALL / PERFORM

pgsql-jdbc by date

Next:From: Guy RouillierDate: 2006-02-14 00:07:09
Subject: JDBC support for CALL / PERFORM
Previous:From: Guy RouillierDate: 2006-02-13 22:11:47
Subject: JDBC support for CALL / PERFORM

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group