Re: second DML operation fails with updatable cursor

Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Our FOR UPDATE cursors aren't exactly INSENSITIVE right now.

Yeah, after re-absorbing the code I realized my earlier comment was out
of date.  I think the true state of affairs is (or should be) that a
cursor declared with FOR UPDATE is sensitive and one without is
insensitive.

>> Another question: if you do DELETE WHERE CURRENT OF, what would you
>> expect to happen to the cursor position?

> According to the spec: before the next row.

AFAICS we cannot really support that without some fairly major revisions
to the way things work --- there's no concept in either the executor or
the cursor-movement stuff of a "hole" within a query's tuple series.
However, the only case that would misbehave is if you try to re-fetch
a row you just deleted, which is a pretty strange thing to do (and
forbidden by spec anyway, I believe) so I think we can leave it as an
unfixed issue for now.  The refetch-after-UPDATE case seems important to
fix, though.
        regards, tom lane