Re: second DML operation fails with updatable cursor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
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:10:53
Message-ID: 9909.1193249453@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-10-24 18:23:28 Re: second DML operation fails with updatable cursor
Previous Message Heikki Linnakangas 2007-10-24 17:59:37 Re: second DML operation fails with updatable cursor