Tom Lane wrote:
>
> Ian Lance Taylor <ian@airs.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
andthe 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,
itcould neither move nor remove the tuple but I'm not sure if the new VACUUM could remove the deleted tuple and other
backendscould re-use the space under such a situation. If it's possible, there must be another information like OID
toiden- tify tuples.
Anyway optional OIDs aren't preferable IMHO.
regards,
Hiroshi Inoue