On Wed, Oct 12, 2011 at 12:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm. I had been supposing that lossless compress functions would just be no-ops. If that's not necessarily the case then we might need something different from the opclass's decompress function to get back the original data. However, that doesn't really solve the problem I'm concerned about, because the existence and use of such a function would be entirely internal to GiST. There still needs to be a way for the planner to know which opclasses support data retrieval. And I do *not* want to see us hard-wire "the presence of opclass function 8 means a GiST opclass can return data" into the planner.
Maybe, instead of a simple constant amcanreturn column, we need an AM API function that says whether the index can return data.
I like idea of such AM API function. Since single multicolumn index can use multiple opclasses, AM API function should also say *what* data index can return.
