On Sun, Sep 20, 2020 at 6:36 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Thu, Sep 17, 2020 at 5:41 AM Julien Rouhaud <rjuju...@gmail.com> wrote: > > On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut > > <peter.eisentr...@2ndquadrant.com> wrote: > > > I'm confused now. I think we had mostly agreed on the v28 patch set, > > > without this additional AM flag. There was still some discussion on > > > what the AM flag's precise semantics should be. Do we want to work that > > > out first? > > > > That was my understanding too, but since Michael raised a concern I > > wrote some initial implementation for that part. I'm assuming that > > this new flag will raise some new discussion, and I hope this can be > > discussed later, or at least in parallel, without interfering with the > > rest of the patchset. > > If we always record dependencies we'll have the option to invent > clever ways to ignore them during version checking in later releases.
But in any case we need to record the dependencies for all collations right? The only difference is that we shouldn't record the collation version if there's no risk of corruption if the underlying sort order changes. So while I want to address this part in pg14, if that wasn't the case the problem would anyway be automatically fixed in the later version by doing a reindex I think, as the version would be cleared. There could still be a possible false positive warning in that case if the lib is updated, but users could clear it with the infrastructure proposed. Or alternatively if we add a new backend filter, say REINDEX (COLLATION NOT CURRENT), we could add there additional knowledge to ignore such cases. > > > Btw., I'm uneasy about the term "stable collation order". "Stable" has > > > an established meaning for sorting. It's really about whether the AM > > > uses collations at all, right? > > > > Well, at the AM level I guess it's only about whether it's using some > > kind of sorting or not, as the collation information is really at the > > opclass level. It makes me realize that this approach won't be able > > to cope with an index built using (varchar|text)_pattern_ops, and > > that's probably something we should handle correctly. > > Hmm. 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?