|
Home > Archive > PostgreSQL JDBC > February 2006 > JDBC support for CALL / PERFORM
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
JDBC support for CALL / PERFORM
|
|
| Guy Rouillier 2006-02-13, 8:25 pm |
| Moved from the INTERFACES list.
Kris Jurka wrote:
> On Mon, 13 Feb 2006, Guy Rouillier wrote:
>
>
> 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
Ok, thanks. I haven't begun to look at the code yet, but the general
approach will be
(1) Execute each statement in the batch one at a time.
(2) If a particular statement encounters this one error (result not
allowed in batch), and if the statement is a callable statement, then
absorb the error, discard the result set and continue.
(3) Otherwise (not this particular error or not a callable statement),
then allow the error to propagate as currently implemented.
The reason I started out with the idea of introducing CALL and/or
PERFORM is that a non-trivial amount of Java code working with Oracle
uses SQL strings that begin "call ...", i.e., not an escaped call but an
actual Oracle-proprietary SQL call. While doing as I suggested make
converting such code easier, I understand that introducing one kludge to
accommodate another is probably not a great idea. Better to have the
programmer go back and fix the original kludge.
--
Guy Rouillier
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Kris Jurka 2006-02-13, 8:25 pm |
|
On Mon, 13 Feb 2006, Guy Rouillier wrote:
>
> Ok, thanks. I haven't begun to look at the code yet, but the general
> approach will be
>
> (1) Execute each statement in the batch one at a time.
> (2) If a particular statement encounters this one error (result not
> allowed in batch), and if the statement is a callable statement, then
> absorb the error, discard the result set and continue.
> (3) Otherwise (not this particular error or not a callable statement),
> then allow the error to propagate as currently implemented.
>
All you should have to modify is
org.postgresql.jdbc2. AbstractJdbc2Stateme
nt.BatchResultHandler.handleResultRows
to not throw an Exception if you've got a CallableStatement.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
|
|
|
|
|