Common definitions for cursor types.
In C++ terms, fetches are always done in pre-increment or pre-decrement fashion–i.e. the result does not include the row the cursor is on at the beginning of the fetch, and the cursor ends up being positioned on the last row in the result.
There are singular positions akin to end()
at both the beginning and the end of the cursor's range of movement, although these fit in so naturally with the semantics that one rarely notices them. The cursor begins at the first of these, but any fetch in the forward direction will move the cursor off this position and onto the first row before returning anything.
Cursor destruction policy.
The normal thing to do is to make a cursor object the owner of the SQL cursor it represents. There may be cases, however, where a cursor needs to persist beyond the end of the current transaction (and thus also beyond the lifetime of the cursor object that created it!), where it can be "adopted" into a new cursor object. See the basic_cursor documentation for an explanation of cursor adoption.
If a cursor is created with "loose" ownership policy, the object representing the underlying SQL cursor will not take the latter with it when its own lifetime ends, nor will its originating transaction.
- Warning
- Use this feature with care and moderation. Only one cursor object should be responsible for any one underlying SQL cursor at any given time.
-
Don't "leak" cursors! As long as any "loose" cursor exists, any attempts to deactivate or reactivate the connection, implicitly or explicitly, are quietly ignored.
Enumerator |
---|
owned | Destroy SQL cursor when cursor object is closed at end of transaction.
|
loose | Leave SQL cursor in existence after close of object and transaction.
|