Re: CURRENT OF cursor without OIDs

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

> >    There could be DELETE operations for the tuple
> >    from other backends also and the TID may disappear.
> >    Because FULL VACUUM couldn't run while the cursor
> >    is open, it could neither move nor remove the tuple
> >    but I'm not sure if the new VACUUM could remove
> >    the deleted tuple and other backends could re-use
> >    the space under such a situation.
> 
> If you also save the tuple transaction info (xmin ?) during the
> select in addition to xtid, you could see whether the tupleslot was
> reused ?
> (This might need a function interface to make it reasonably portable to
> future 
> versions)
> Of course the only thing you can do if you notice it has changed is bail
> out.
> But that leaves the question to me on what should actually be done when
> the tuple has changed underneath. 
> I for one would not like the update to succeed if someone else modified
> it 
> inbetween my fetch and my update.

If PL/pgSQL doesn't lock the table before doing the select, then I
think it has to mark the tuples for update when it does the select.
Unfortunately, the portal code explicitly rejects FOR UPDATE
(transformSelectStmt in parser/analyze.c).

Ian