Re: modification required to pass Sun's CTS
От | Oliver Jowett |
---|---|
Тема | Re: modification required to pass Sun's CTS |
Дата | |
Msg-id | 429EED51.5010801@opencloud.com обсуждение исходный текст |
Ответ на | Re: modification required to pass Sun's CTS (Dave Cramer <pg@fastcrypt.com>) |
Список | 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
В списке pgsql-jdbc по дате отправления: