> I am not sure there's anything fundamentally wrong with his basic point;
> if, say, we could find a way to construct OIDs so that a tuple could be
> found very quickly from its OID, that wouldn't violate the relational
> model AFAICS, and such OIDs would work fine as "links". But I don't see
> any way to do that without either giving up UPDATE or introducing a huge
> amount of baggage into all processes that can update tables (VACUUM
> being the worst case, likely). Without doubt the best compromise would
> look remarkably like an index on OID.
>
I think the best compromise would be to have ctid in the where clause.
This would need to always be considered as best path by the optimizer.
Then the situation is similar to a primary key foreign key scenario.
The referenced table does not need an index, since we know the physical
position of the row we want (where ctid='(5,255)').
What we need second is an update trigger for the referenced table that
updates old.ctid to new.ctid in the referencing table. For this to be
efficient
you would need to create an index on the column that stores the reference.
I do not actually think that we would need extra syntax to allow this,
only the access method for a ctid where clause.
Andreas
