I wrote: > Maybe we should redefine the API as involving a TupleTableSlot that > the AM is supposed to fill --- basically, moving StoreIndexTuple > out of the common code in nodeIndexonlyscan.c and requiring the AM > to do that work. The possible breakage of third-party code is a > bit annoying, but there can't be all that many third-party AMs > out there yet.
After looking a bit at gist and sp-gist, neither of them would find that terribly convenient; they really want to create one blob of memory per index entry so as to not complicate storage management too much. But they'd be fine with making that blob be a HeapTuple not IndexTuple. So maybe the right approach is to expand the existing API to allow the AM to return *either* a heap or index tuple; that could be made to not be an API break. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers