Re: modification required to pass Sun's CTS
От | Oliver Jowett |
---|---|
Тема | Re: modification required to pass Sun's CTS |
Дата | |
Msg-id | 429E2AB3.7080405@opencloud.com обсуждение исходный текст |
Ответ на | modification required to pass Sun's CTS (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: modification required to pass Sun's CTS
|
Список | pgsql-jdbc |
Dave Cramer wrote: > The cts calls executeUpdate on a function with out parameters. > > I know the API says that executeUpdate is only to be used when no > results are expected, > but this is the way the test is. > > > Any thoughts on changing executeUpdate to allow results to be returned? That's almost certainly the wrong thing to do. executeUpdate is quite specific about throwing exceptions when a resultset is returned. I think the confusion arises from JDBC not considering an OUT parameter to be a "result". i.e. you can have a function with OUT parameters that returns a resultset, but equally you can have one that doesn't return a resultset; and the values in the resultset (if any) are separate to the returned OUT parameter values. Given that the backend OUT parameter support is implemented as a resultset, maybe it makes sense to hide the resultset of a function with OUT parameters entirely, since it's really an implementation artifact? Then executeUpdate shouldn't need changes. Does the CTS have the reverse case, i.e. requiring a function that has both OUT parameters and a resultset? Seems like that'd be hard to support at all with the current scheme.. -O
В списке pgsql-jdbc по дате отправления: