Re: REINDEX backend filtering

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.

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"?

> 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".