Re: Collation versioning
От | Thomas Munro |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | CA+hUKGKop8pe3ijVna6ZUA3cGdjy8egm5geUuPJqM91smjLjYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Collation versioning
|
Список | pgsql-hackers |
On Thu, Sep 17, 2020 at 5:41 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > On Tue, Sep 15, 2020 at 2:26 PM Peter Eisentraut > <peter.eisentraut@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. > > 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.
В списке pgsql-hackers по дате отправления: