Re: [PATCH] Covering SPGiST index

I wrote:
> I spent a little time looking at this, and realized something that may
> or may not be a serious problem. This form of the patch supposes that
> it can use the usual tuple form/deform logic for all columns of a leaf
> tuple including the key column. However, that does not square with
> SPGIST's existing storage convention for pass-by-value key types: we
> presently assume that those are stored in their Datum representation,
> ie always 4 or 8 bytes depending on machine word width, even when
> typlen is less than that.

> Now there is an argument why this might not be an unacceptable disk
> format breakage: there probably aren't any SPGIST indexes with a
> pass-by-value leaf key type.

On further contemplation, it occurs to me that if we make the switch
to "key values are stored per normal rules", then even if there is an
index with pass-by-value keys out there someplace, it would only break
on big-endian architectures. On little-endian, the extra space
occupied by the Datum format would just seem to be padding space.
So this probably means that the theoretical compatibility hazard is
small enough to be negligible, and we should go with my option #2
(i.e., we need to replace SGLTDATUM with normal attribute-fetch logic).

regards, tom lane