Re: persistent portals/cursors (between transactions)

> > > But I don't like the idea of cross transaction cursors. The
> > > locking issues, mentioned in the code by MAO, which are the
> > > reason for rejecting FOR UPDATE on cursors, should be gone.
> > > And the capability to select for update is a requirement for
> > > updateable cursors, that I intend to work on for 7.3.
> >
> > But can't cursors not only be updateable inside transactions and
> > read-only outside transactions, as a work-around, which would bring
> > PostgreSQL at least a little closer to the standard?
> >
> > And in the long term, can't the lock that is acquired with FOR UPDATE be
> > released when the cursor is closed and not when the transaction is
> > finished?
>
> The way it has to be is that you say
>
> UPDATE ... WHERE CURRENT OF <cursor>
>
> My idea is to hold the CTID, retrieved via a junk attribute,
> of the last FETCH'ed row (of the table the locks are for)
> inside of the cursor information, and basically rewrite the
> WHERE CURRENT OF into a WHERE ctid = ... during parse.
>
> As long as we cannot safely hold such locks across Xact
> boundaries and guarantee that rows locked that way don't get
> moved by vacuum, I'd vote for making cursors that are FOR
> UPDATE inaccessable at Xact end.

As long as the cursor is not insensitive, as it has to keep vacuum from
removing rows then anyway. Though the lock would then still be necessary
for obvious reasons too.

And Hiroshi wrote in this thread in
<EKEJJICOHDIEMGPNIFIJEEDKGJAA(dot)Inoue(at)tpf(dot)co(dot)jp> that Tom already
implemented cross transaction locking, though I don't know if this can
be applied here.

> Reminds me that Al Dev is right. The law's of physics apply
> to software! Proof: vacuum sucks!

:))