> 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