Tom Lane wrote:
> The cursor must be considered to be positioned on its current row, not
> between rows, or the SQL-defined operations UPDATE WHERE CURRENT OF and
> DELETE WHERE CURRENT OF don't make any sense. (We don't support those
> yet, but we should someday.)
Okay. But then doesn't it make sense for FETCH to fetch the contents
of the row (and subsequent requested rows) that the cursor is
currently on *then* move, and not the other way around? Were that the
model, then the only situation in which the cursor would not be on a
row is if it's past the last one (or if it pointed to an empty set).
And the initial declaration of the cursor would thus normally place
the cursor on the first row fetched, just as you'd expect.
"Fetch 3" would fetch whatever row the cursor is currently on and the
following 2 rows, then move the cursor down 3 rows (so that it's on
the row that follows the last row fetched).
Additionally, with that model, UPDATE WHERE CURRENT OF would work
exactly as you'd expect in all situations: it would update the row the
cursor is on or, if the cursor is beyond the last row, would fail.
MOVE would also work exactly as you'd expect: MOVE -3 would move the
cursor back 3 positions, or to the beginning of the set, whichever
comes first, and would report how many positions it was able to move.
My read of the spec indicates that cursors don't behave the way I
describe above. If I'm right, then does anyone here know why the spec
calls for something different?
--
Kevin Brown kevin@sysexperts.com