Bernt M. Johnsen wrote:
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;
  
Not all databases require a Cursor though to retrieve  and access results.
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.)
  
Positioned updates have been supported since JDBC 1.0.2 and the semantics behavior have not changed, even with the addition of updatable ResultSets.
Anyway, I always thought that the semantic relation between the JDBC
spec and the SQL standard were far to vague. 

  
Unfortunately it will be  that way in many cases ala ODBC.  While things i think continue to improve, it is hard to reach concensus and approval  given some of these databases are 20+ years old and cannot or willnot change.

It is easier for new features to keep them closer in line with the SQL standard, but for older features it is not quite that easy (though it leads to interesting disccussons at the EG meetings)


  
[...]

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.