Skip site navigation (1) Skip section navigation (2)

Re: second DML operation fails with updatable cursor

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dharmendra Goyal <dharmendra(dot)goyal(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: second DML operation fails with updatable cursor
Date: 2007-10-24 18:24:51
Message-ID: 471F8DF3.5050508@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-24 18:35:53
Subject: Re: second DML operation fails with updatable cursor
Previous:From: Simon RiggsDate: 2007-10-24 18:23:28
Subject: Re: second DML operation fails with updatable cursor

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group