1. Table AM with a 6-byte TID.
2. Table AM with a custom locator format, which could be TID-like.
3. Table AM with no locators.
Currently TID has its own type in system catalog. Seems, it's possible that
storage claims type of TID which it uses. Then, AM could claim it too, so the
core based on that information could solve the question about AM-storage
compatibility. Storage could also claim that it hasn't TID type at all so it
couldn't be used with any access method, use case: compressed column oriented
storage.
As I remeber, only GIN depends on TID format, other indexes use it as opaque
type. Except, at least, btree and GiST - they believ that internal pointers are
the same as outer (to heap)
Another dubious part - BitmapScan.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
