Jeff Davis <pg...@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