From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: modification required to pass Sun's CTS |
Date: | 2005-06-02 11:28:17 |
Message-ID: | 429EED51.5010801@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Dave Cramer wrote:
> OK, so if I understand this correctly, we allow the OUT parameter
> result set if it is a callablestatement ?
No. I guess I'm not being clear.
If you have a function that does not return anything, but has OUT
parameters, then CallableStatement.executeUpdate() should succeed and
CallableStatement.executeQuery() should fail. That is, the fact that we
use a SELECT to get at the OUT parameters is an *implementation detail*
-- from the point of view of the JDBC {call} escape, the function is
*not* returning a resultset.
So the driver's implementation of OUT parameters should also make sure
to suppress the resultset generated by the SELECT. From the point of
view of the JDBC client, execution of the {call} escape *does not return
a resultset*. That means that executeUpdate() doesn't complain about it,
and executeQuery() *does* complain about it, and you can't get access to
any resultset via getResultSet() etc. If you want to get the OUT
values, you use the appropriate parameter-getting methods on
CallableStatement.
> I don't think we can actually return two resultsets ie one for the out
> parameters, and yet another if the function returns a resultset. I
> don't believe the
> backend has this facility.
Yes, that's what I said in my earlier email.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2005-06-03 12:52:00 | CTS compatibility TINYINT type ? |
Previous Message | Dave Cramer | 2005-06-02 11:18:35 | Re: modification required to pass Sun's CTS |