Clarify what's supposed to happen when a cursor FETCH is rolled back

by aborting a subtransaction.  Per discussion with Heikki.

diff --git a/doc/src/sgml/ref/rollback_to.sgml b/doc/src/sgml/ref/rollback_to.sgml
index c0d386b9652fd3182ca129fb7a69c6e4b1f159f3..414f450a41d8972ec929f85aed4dc533b3444ee9 100644 (file)
--- a/doc/src/sgml/ref/rollback_to.sgml
+++ b/doc/src/sgml/ref/rollback_to.sgml
@@ -1,5 +1,5 @@
 
 
@@ -77,11 +77,14 @@ ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name
    Cursors have somewhat non-transactional behavior with respect to
    savepoints.  Any cursor that is opened inside a savepoint will be closed
    when the savepoint is rolled back.  If a previously opened cursor is
-   affected by a 
-   FETCH command inside a savepoint that is later rolled
-   back, the cursor position remains at the position that FETCH
-   left it pointing to (that is, FETCH is not rolled back).
+   affected by a FETCH or MOVE command inside a
+   savepoint that is later rolled back, the cursor remains at the
+   position that FETCH left it pointing to (that is, the cursor
+   motion caused by FETCH is not rolled back).
    Closing a cursor is not undone by rolling back, either.
+   However, other side-effects caused by the cursor's query (such as
+   side-effects of volatile functions called by the query) are
+   rolled back if they occur during a savepoint that is later rolled back.
    A cursor whose execution causes a transaction to abort is put in a
    cannot-execute state, so while the transaction can be restored using
    ROLLBACK TO SAVEPOINT, the cursor can no longer be used.