• Tom Lane's avatar
    Fix SP-GiST scan initialization logic for binary-compatible cases. · 6d07cbc5
    Tom Lane authored
    Commit ac9099fc rearranged the logic in spgGetCache() that determines
    the index's attType (nominal input data type) and leafType (actual
    type stored in leaf index tuples).  Turns out this broke things for
    the case where (a) the actual input data type is different from the
    nominal type, (b) the opclass's config function leaves leafType
    defaulted, and (c) the opclass has no "compress" function.  (b) caused
    us to assign the actual input data type as leafType, and then since
    that's not attType, we complained that a "compress" function is
    required.  For non-polymorphic opclasses, condition (a) arises in
    binary-compatible cases, such as using SP-GiST text_ops for a varchar
    column, or using any opclass on a domain over its nominal input type.
    
    To fix, use attType for leafType when the index's declared column type
    is different from but binary-compatible with attType.  Do this only in
    the defaulted-leafType case, to avoid overriding any explicit
    selection made by the opclass.
    
    Per bug #17294 from Ilya Anfimov.  Back-patch to v14.
    
    Discussion: https://postgr.es/m/17294-8f6c7962ce877edc@postgresql.org
    6d07cbc5
spgist.out 3.72 KB