Re: CURRENT OF cursor without OIDs

Tom Lane wrote:
>
> Ian Lance Taylor <ian(at)airs(dot)com> writes:
> > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > My question now is: if there is no OID, is there any comparable way to
> > implement CURRENT OF cursor? Basically what is needed is some way to
> > identify a particular row between a SELECT and an UPDATE.
>
> I'd look at using TID. Seems like that is more efficient anyway (no
> index needed). Hiroshi has opined that TID is not sufficient for ODBC
> cursors, but it seems to me that it is sufficient for SQL cursors.
>

Yes TID is available and I introduced Tid Scan in order
to support this kind of implementation. However there
are some notices.
1) Is *FOR UPDATE* cursor allowed in PL/pgSQL ?
(It doesn't seem easy for me).
2) If no, there could be UPDATE operations for the
current tuple from other backends between a
SELECT and an UPDATE and the TID may be changed.
In that case, you couldn't find the tuple using
saved TID but you could use the functions to
follow the UPDATE link which I provided when I
I introduced Tis Scan.
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 it's possible,
there must be another information like OID to iden-
tify tuples.

Anyway optional OIDs aren't preferable IMHO.

regards,
Hiroshi Inoue