Jeff Davis <pgsql@j-davis.com> writes:
> The notion of TID is based on pages and line pointers, which makes
> sense for heapam, but that's not likely to make sense for a custom
> table AM.
> The obvious answer is to make a simple mapping between a TID and
> whatever makes sense to the AM (for the sake of discussion, let's say a
> plain row number).
I'm inclined to think that when we get around to doing something
about this, we need to make a much bigger change than just poking
at the margins of type tid.
My thought at the moment is that all APIs above the AM level ought
to be redefined to use uint64 for tuple identifiers. heapam and
related index AMs could map block + offset into that in some
convenient way, and other AMs could do what they like.
Andres seems to feel that we should try to allow variable-width
tupleids, but I'm afraid that the cost/benefit ratio for that
would be pretty poor.
regards, tom lane
