Re: second DML operation fails with updatable cursor - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: second DML operation fails with updatable cursor
Date
Msg-id 471F8DF3.5050508@enterprisedb.com
Whole thread Raw
In response to Re: second DML operation fails with updatable cursor  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: second DML operation fails with updatable cursor
List pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: second DML operation fails with updatable cursor
Next
From: Tom Lane
Date:
Subject: Re: second DML operation fails with updatable cursor