Re: second DML operation fails with updatable cursor

Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>> 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.

Yes, re-fetching row you just deleted is supposed to raise an error.
That doesn't seem very hard to implement. If an UPDATE/DELETE CURRENT OF
doesn't find the tuple to update/delete, raise an error.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com