[
https://issues.apache.org/jira/browse/DERBY-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4164:
---------------------------------
Attachment: rrefsqljrevoke-3.html
derby-4164-3.diff
Thanks for looking at this Kim!
I agree, the wording I used for "execute" was awkward; I was trying to refer to
the JDBC "execute" method in order to use a more specific term than
"execution", which could possibly be construed as also referring the fetching
of rows from the result set/cursor, but thinking about it again, "execution" is
better. Your other edits also improve readability.
I upload a third version (with HTML for convenience), in which I make the
sentence about the
result set start a new paragraph, to avoid giving the impression that this
description only
applies when prepared statements are used; it also holds when direct execution
is used, of course.
Do you think I would be better to use a separate section to further clarify
this?
> Make REVOKE statement description mention what happens for open result
> sets/cursors
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4164
> URL: https://issues.apache.org/jira/browse/DERBY-4164
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Reporter: Dag H. Wanvik
> Priority: Minor
> Fix For: 10.6.0.0
>
> Attachments: derby-4164-2.diff, derby-4164-3.diff, derby-4164.diff,
> rrefsqljrevoke-3.html, rrefsqljrevoke.html
>
>
> When a REVOKE statement is executed, already open result sets are not
> impacted. This should be mentioned
> in the user documentation, at least here: ref/rrefsqljrevoke.html.
> Permissions are checked at statement execute time; if this succeeds, a
> cursor/result set will be able to access all rows
> in the result set even if privileges/roles are revoked after the execute but
> before the result set/cursor is closed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
