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

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


pgsql-hackers by date:

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