Re: Collation versioning

On Thu, Sep 24, 2020 at 9:49 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> 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)

I think we should try to get the basic feature into the tree, and then
look at these kinds of subtleties as later improvements. Here's a new
version with the following changes:

1. Update the doc patch to mention that this stuff now works on
Windows too (see commit 352f6f2d).
2. Drop non_deterministic_only argument for from GetTypeCollations();
it was unused.
3. Drop that "stable collation order" field at the AM level for now.
This means that we'll warn you about collation versions changes for
hash and bloom indexes, even when it's technically unnecessary, for
now.

The pattern ops stuff seems straightforward however, so let's keep
that bit in the initial commit of the feature. That's a finite set of
hard coded op classes which exist specifically to ignore collations.