On Sun, Sep 20, 2020 at 10:24:26AM +0800, Julien Rouhaud wrote:
>
> On the other hand the *_pattern_ops are entirely hardcoded, and I
> don't think that we'll ever have an extensible way to have this kind
> of magic exception. So maybe having a flag at the am level is
> acceptable?
Hearing no complaint, I kept the flag at the AM level and added hardcoded
exceptions for the *_pattern_ops opclasses to avoid false positive as much as
possible, and no false negative (at least that I'm aware of). I added many
indexes to the regression tests to make sure that all the cases are correctly
handled.
Unfortunately, there's still one case that can't be fixed easily. Here's an
example of such case:
CREATE INDEX ON sometable ((collatable_col || collatable_col) text_pattern_ops)
In this case when iterating over the key columns, the current patch notices
that a dependency on the collation should be added but that the version
shouldn't be tracked, as it's text_pattern_ops. But then the expression itself
is processed, and it also see that a dependency on the collation should be
addedd. However, it has no way to know that it should not update the
previously recorded dependency to start tracking the version, as the expression
could really depends on a stable order.
So we end up with a single dependency (which is what we want I think), but
which will report false positive warning in case of collation lib update.
v30 attached.
