Re: REINDEX backend filtering

On Thu, Feb 25, 2021 at 07:36:02AM +1300, Thomas Munro wrote:
> On Thu, Feb 25, 2021 at 1:22 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > #define reindexHasFilter(x) ((x & REINDEXOPT_COLL_NOT_CURRENT) != 0)
>
> It's better to use "(x) & ..." in macros to avoid weird operator
> precedence problems in future code.

Ah indeed, thanks! I usually always protect the arguments wth parenthesis but
I somehow missed this one. I'll send a new version of the patch shortly with
the rest of the problems you mentioned.

> It seems like there are several different names for similar things in
> this patch: "outdated", "not current", "deprecated". Can we settle on
> one, maybe "outdated"?

Oops, I apparently missed a lot of places during the various rewrite of the
patch. +1 for oudated.

>
> > The code as-is written to be extensible with possibly other filters
> > (e.g. specific library or specific version). Feedback so far seems to
> > indicate that it may be overkill and only filtering indexes with
> > deprecated collation is enough. I'll simplify this code in a future
> > version, getting rid of reindexHasFilter, unless someone thinks more
> > filter is a good idea.
>
> Hmm, yeah, I think it should probably be very general. Suppose someone
> invents versioned dependencies for (say) functions or full text
> stemmers etc, then do we want to add more syntax here to rebuild
> indexes (assuming we don't use INVALID for such cases, IDK)? I don't
> think we'd want to have more syntax just to be able to say "hey,
> please fix my collation problems but not my stemmer problems". What
> about just REINDEX (OUTDATED)? It's hard to find a single word that
> means "depends on an object whose version has changed".

That quite make sense. I agree that it would make the solution simpler and
better.

Looking at the other use case for PostGIS mentioned by Darafei, it seems that
it would help to make concept of index dependency extensible for third party
code too (see
https://www.postgresql.org/message-id/20210226074531.dhkfneao2czzqk6n%40nol).
Would that make sense?