Re: Collation versioning
От | Thomas Munro |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | CA+hUKGKewJO4Cb4G_p5Mu7M5fSFSRg1aWXK6aTXHoY0HMMwWtg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Collation versioning
Re: Collation versioning |
Список | pgsql-hackers |
On Thu, Oct 3, 2019 at 7:53 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 2018-09-05 23:18, Thomas Munro wrote: > > On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg <myon@debian.org> wrote: > >>> So, it's not ideal but perhaps worth considering on the grounds that > >>> it's better than nothing? > >> > >> Ack. > > > > Ok, here's a little patch like that. > > > > postgres=# select collname, collcollate, collversion from pg_collation > > where collname = 'en_NZ'; > > collname | collcollate | collversion > > ----------+-------------+------------- > > en_NZ | en_NZ.utf8 | 2.24 > > (1 row) > > After, um, briefly sleeping on this, I would like to go ahead with this. > > There is ongoing work to make ICU available globally, and as part of > that I've also proposed a way to make the collation version tracking > work on a database level. > > This here would be a useful piece on the overall picture. Independent > of what becomes of the ICU effort, we could have glibc collation version > tracking completely working for PG13. +1 Also, better ideas about which objects to attach versions to can come along independently of this. > The only open question on this patch was whether it's a good version to > use. I think based on subsequent discussions, there was the realization > that this is the best we can do and better than nothing. > > In the patch, I would skip the configure test and just do > > #ifdef __GLIBC__ > > directly. Ok. Here's one like that. Also, a WIP patch for FreeBSD. Thanks, Thomas
Вложения
В списке pgsql-hackers по дате отправления: