>>>>>>>>>>>> Daniel John Debrunner wrote (2005-11-03 19:17:58): > Thanks for the useful infomation, but how are you inferring those cursor > context attributes from the JDBC ResultSet being read-only?
I consider e.g. the prepareStatement/executeQuery combination to be
the JDBC equivalent to the SQL/Language (ISO/IEC 9075-5) prepare
statement/declare cursor combination.
Thus when you in JDBC writes
PreparedStatement p = c.prepareStatement("SELECT * FROM T");
ResultSet rs = p.executeQuery();
it is equivalent to
PreparedStatement p = c.prepareStatement("SELECT * FROM T",
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = p.executeQuery();
which again should be equivalent something like
PREPARE p FROM SELECT * FROM T FOR READ ONLY;
DECLARE rs NO SCROLL CURSOR FOR p;
BUT: Your concern about legacy is of course very important (I did not
do any JDBC work prior to 2.0, and then for a database which do not
support updatable cursors.)
Anyway, I always thought that the semantic relation between the JDBC
spec and the SQL standard were far to vague.
> [...]
>
> The patch can probably proceed without this being resolved,
Yes, the patch should proceed, but with a proper comment.
> but it would be good to come to clear agreement on if SELECT * FROM
> T can be updated with a positioned update/delete and a read-only
> ResultSet. (Even if Derby doesn't support it today, it would be nice
> to know or not if it is meant to be supported).
It definitely would mean lower performance due to locking issues.
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway
pgp6UhUISlEAj.pgp
Description: PGP signature
