Re: second DML operation fails with updatable cursor

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:23:28
Message-ID: 1193250208.4242.166.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2007-10-24 at 18:29 +0100, Heikki Linnakangas wrote:

> >> FETCH RELATIVE 0 re-fetches the current row according to the
> manual.
> >
> > The question is what's the current row, remembering that we've
> always
> > defined our cursors as INSENSITIVE.
>
> I tried to find an answer to that in the spec. I'm pretty you're
> supposed to see the changes of UPDATEs done through the same cursor,
> using WHERE CURRENT OF, even with insensitive cursors. I have no idea
> how we could implement that, though.

AFAICS in all cases I can find, SCROLLABLE => INSENSITIVE => no UPDATEs.

ISTM we should just restrict Updateable cursors to be non-scrollable,
plus force non-scrollable if the user hasn't specified scrollability but
has specified updateability. That makes sense, since currently we
restrict updateable cursors to not be also specified WITH HOLD.

If we work out a way that makes sense then we can extend the behaviour
in the next release to include scrollable && updateable at the same
time.

That catches all the problems raised here, I believe.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-10-24 18:24:51 Re: second DML operation fails with updatable cursor
Previous Message Tom Lane 2007-10-24 18:10:53 Re: second DML operation fails with updatable cursor