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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-10-24 18:35:53|
|Subject: Re: second DML operation fails with updatable cursor |
|Previous:||From: Simon Riggs||Date: 2007-10-24 18:23:28|
|Subject: Re: second DML operation fails with updatable cursor|