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=zymja...@mail.gmail.com for both cases.
