Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Tue, Oct 11, 2011 at 5:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I haven't thought as far ahead as how we might get the information
>> needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
>> CLASS might be the only way.
>>
> Shouldn't it be implemented through additional interface function? There are
> situations when restoring of original tuple requires some transformation.
> For example, in point_ops we store box in the leaf index tuple, while point
> can be easily restored from box.
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.
regards, tom lane
