> Now that the input data type and leaf data type can be different, which one is
> "attType"? It's the leaf data type, as the patch stands. I renamed that to
> attLeafType, and went fixing all the references to it. In most places it's just
> a matter of search & replace, but what about the reconstructed datum? In
> freeScanStackEntry, we assume that att[Leaf]Type is the datatype for
> reconstructedValue, but I believe assume elsewhere that reconstructedValue is of
> the same data type as the input. At least if the opclass supports index-only scans.
Agree with rename. I doubt that there is a real-world example of datatype which
can be a) effectivly compressed and b) restored to original form. If so, why
don't store it in compressed state in database? In GiST all compress methods
uses one-way compress. In PostGIS example, polygons are "compressed" into
bounding box, and, obviously, they cannot be restored.
>
> I think we'll need a separate SpGistTypeDesc for the input type. Or perhaps a
> separate SpGistTypeDesc for the reconstructed value and an optional decompress
> method to turn the reconstructedValue back into an actual reconstructed input
> datum. Or something like that.
I suppose that compress and reconstruct are mutual exclusive options.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/