Re: persistent portals/cursors (between transactions)

> > 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.
>
>     Reminds me that Al Dev is right. The law's of  physics  apply
>     to software!  Proof: vacuum sucks!

I am not sure that is true anymore of non-FULL vacuum.  I thought it
didn't move tids, though it will remove expired ones.  Tom?

Wonder if we should think of some kind of anti-FULL vacuum lock that can
be held during transactions with FOR UPDATE.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026