
> I believe the ODBC driver uses CTID for this sort of problem.  CTID is
> guaranteed to exist and to be fast to access (since it's a physical
> locator).  Against this you have the problem that concurrent updates
> of the record will move it, leaving your CTID invalid.  However, that

IIRC the ctid access follows the chain up to the currently valid 
tuple ? I thought the only enemy of ctid access was "vacuum" ?

Andreas

Thu, 19 Feb 2004 16:09:44 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: OIDs, CTIDs, updateable cursors and friends
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> IIRC the ctid access follows the chain up to the currently valid 
> tuple ?

No.

I think Hiroshi or someone put in a function you can use to follow the
chain, but a simple "WHERE ctid = whatever" won't do it.  In any case,
if you're not holding an open transaction then you have to be prepared
to have the dead tuple vacuumed out from under you, in which case you'd
not be able to follow the chain anyway.

			regards, tom lane

Thu, 19 Feb 2004 11:01:14 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: OIDs, CTIDs, updateable cursors and friends 