Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > Tom Lane wrote: >> What are you going to do for index types that don't store the original >> data (e.g. hash)?
> They will obviously not be able to regurgitate index tuples. I have not > yet decided how that's going to be signaled. Well, I think that's a pretty critical part of the API change. > (This indexam API patch isn't bothered with that yet. It just splits > index_gettuple() into two) One thought here is that an AM call isn't really free, and doing two of them instead of one mightn't be such a good idea. I would suggest either having a separate AM entry point to get both bits of data ("amgettupledata"?) or adding an optional parameter to amgettuple. A small attraction of the alternate entry point is that then you can flag the "unsupported" case by putting a zero in that pgam column, as indeed we already do for amgettuple; so you don't need an additional bool column. [ thinks a bit ... ] At least for GIST, it is possible that whether data can be regurgitated will vary depending on the selected opclass. Some opclasses use the STORAGE modifier and some don't. I am not sure how hard we want to work to support flexibility there. Would it be sufficient to hard-code the check as "pgam says the AM can do it, and the opclass does not have a STORAGE property"? Or do we need additional intelligence about GIST opclasses? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers