|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/ref/rollback_to.sgml,v 1.10 2008/11/14 10:22:47 petere Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/rollback_to.sgml,v 1.11 2009/12/02 21:11:12 tgl Exp $ |
3 | 3 | PostgreSQL documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -77,11 +77,14 @@ ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] <replaceable>savepoint_name</re |
77 | 77 | Cursors have somewhat non-transactional behavior with respect to |
78 | 78 | savepoints. Any cursor that is opened inside a savepoint will be closed |
79 | 79 | when the savepoint is rolled back. If a previously opened cursor is |
80 | | - affected by a |
81 | | -<command>FETCH</> command inside asavepoint that is later rolled |
82 | | -back, the cursorpositionremains at the positionthat <command>FETCH</> |
83 | | -left it pointing to (that is, <command>FETCH</> is not rolled back). |
| 80 | + affected by a<command>FETCH</> or <command>MOVE</> command inside a |
| 81 | + savepoint that is later rolled back, the cursor remains at the |
| 82 | + position that <command>FETCH</> left it pointing to (that is, the cursor |
| 83 | +motion caused by <command>FETCH</> is not rolled back). |
84 | 84 | Closing a cursor is not undone by rolling back, either. |
| 85 | + However, other side-effects caused by the cursor's query (such as |
| 86 | + side-effects of volatile functions called by the query) <emphasis>are</> |
| 87 | + rolled back if they occur during a savepoint that is later rolled back. |
85 | 88 | A cursor whose execution causes a transaction to abort is put in a |
86 | 89 | cannot-execute state, so while the transaction can be restored using |
87 | 90 | <command>ROLLBACK TO SAVEPOINT</>, the cursor can no longer be used. |
|