Re: REINDEX backend filtering

Hi,

On Wed, Feb 24, 2021 at 09:34:59PM +0300, Darafei "Komяpa" Praliaskouski wrote:
> Hello,
>
> The PostGIS project needed this from time to time. Would be great if
> reindex by opclass can be made possible.
>
> We changed the semantics of btree at least twice (in 2.4 and 3.0), fixed
> some ND mixed-dimension indexes semantics in 3.0, fixed hash index on 32
> bit arch in 3.0.

Oh, I wasn't aware of that. Thanks for bringing this up!

Looking at the last occurence (c00f9525a3c6c) I see that the NEWS item does
mention the need to do a REINDEX. As far as I understand there wouldn't be any
hard error if one doesn't do to a REINDEX, and you'd end up with some kind
of "logical" corruption as the new lib version won't have the same semantics
depending on the number of dimensions, so more or less the same kind of
problems that would happen in case of breaking update of a collation library.

It seems to me that it's a legitimate use case, especially since GiST doesn't
have a metapage to store an index version. But I'm wondering if the right
answer is to allow REINDEX / reindexdb to look for specific opclass or to add
an API to let third party code register a custom dependency. In this case
it would be some kind of gist ABI versioning. We could then have a single
REINDEX option, like REINDEX (OUTDATED) as Thomas suggested in
https://www.postgresql.org/message-id/CA+hUKG+WWioP6xV5Xf1pPhiWNGD1B7hdBBCdQoKfp=zymJajBQ@mail.gmail.com
for both cases.