SP-GiST versus index-only scans

It would not take very much at all to make the SP-GiST stuff support
index-only scans, except for one thing: it's conceivable that an opclass
might choose to store only a lossy version of the original indexed
datum, in which case it'd not be able to reconstruct the datum on
demand.

I'm not sure how likely this is, because the design of SP-GiST forces
root-level leaf tuples to be stored with the original datum, but in
principle leaf tuples at lower levels might have lossy representations.
None of the current opclasses do that, but Oleg and Teodor evidently
foresee such cases, else they'd not have bothered with the recheck
support that's in there. (If the original datum is reconstructable then
the opclass can surely deliver a correct answer for every leaf tuple.)

So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.

We discussed that idea when the index-only-scans patch went in a few
months ago, but blew it off on the grounds that there didn't seem to be
any immediate need for it. Well, the need is here.

I think we should get rid of the pg_am.amcanreturn boolean column and
replace it with an AM support function. btree's would just return
constant true, but I envision SP-GiST's version interrogating the
opclass config function. (If we make the config function return this
info, we don't need to add anything to CREATE OPERATOR CLASS, which
seems like a good thing to me.)

regards, tom lane