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-01 21:37:55 |
Message-ID: | 429E2AB3.7080405@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2005-06-02 00:37:57 | Re: modification required to pass Sun's CTS |
Previous Message | Paul Thomas | 2005-06-01 21:21:56 | Re: Backslashes in Strings being removed |