Re: ICU integration
От | Thomas Munro |
---|---|
Тема | Re: ICU integration |
Дата | |
Msg-id | CAEepm=002fm_RiMY0ZjhDnUPOHhWXnk-GrqNAUk7bYQt2dacHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ICU integration (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: ICU integration
|
Список | pgsql-hackers |
On Sat, Oct 1, 2016 at 3:30 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 9/23/16 2:27 AM, Thomas Munro wrote: >> The warning persists even after I reindex all affected tables (and >> start a new backend), because you're only recording the collation at >> pg_collation level and then only setting it at initdb time, so that >> HINT isn't much use for clearing the warning. I think you'd need to >> record a snapshot of the version used for each collation that was used >> on *each index*, and update it whenever you CREATE INDEX or REINDEX >> etc. There can of course be more than one collation and thus version >> involved, if you have columns with different collations, so I guess >> you'd need an column to hold an array of version snapshots whose order >> corresponds to pg_index.indcollation's. > > Hmm, yeah, that will need more work. To be completely correct, I think, > we'd also need to record the version in each expression node, so that > check constraints of the form CHECK (x > 'abc') can be handled. Hmm. That is quite a rabbit hole. In theory you need to recheck such a constraint, but it's not at all clear when you should recheck and what you should do about it if it fails. Similar for the future PARTITION feature. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: