Kevin Brown <kevin@sysexperts.com> writes:
> 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?
No, because WHERE CURRENT OF operates on the row last returned by FETCH,
according to the spec. AFAICT, the conceptual model I described a
couple messages back corresponds directly to a subset of the SQL92
specification for cursors: "before first row", "on some row", and "after
last row" are all states described by the spec. (It is a subset because
we don't support DELETE WHERE CURRENT OF --- if we did, we'd need
additional states to handle the situation where the cursor is pointing
at a just-deleted row.)
We don't get to define our own behavior for FETCH.
> 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.
How do you figure that? It would operate on the row after the last one
you'd seen, which seems pretty darn bizarre (ie, useless and dangerous)
to me.
regards, tom lane
