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
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 |