Re: [GENERAL] Changing collate & ctype for an existing database
От | rihad |
---|---|
Тема | Re: [GENERAL] Changing collate & ctype for an existing database |
Дата | |
Msg-id | bd55a74f-cb0b-49fd-1f70-b3bbe4729b72@mail.ru обсуждение исходный текст |
Ответ на | Re: [GENERAL] Changing collate & ctype for an existing database (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] Changing collate & ctype for an existing database
|
Список | pgsql-general |
On 07/12/2017 09:31 PM, Tom Lane wrote: > rihad <rihad@mail.ru> writes: >> On 07/12/2017 01:54 PM, Albe Laurenz wrote: >>> As you see, your index is still sorted according to the C collation >>> and scanning it returns wrong results. >> This ordering issue can certainly be classified as an inconsistency, but >> nothing to lose sleep over. Is this all that is normally meant when >> saying "index corruption"? > Laurenz neglected to point out that if the index isn't sorted the way that > the system assumes it is, then searches may fail to find values that are > present (due to descending into the wrong subtree), and by the same token > insertions may fail to enforce uniqueness. That's pretty corrupt in > my book. > > regards, tom lane > What if only English letters are used in the textual indices (ascii 0-127), would they still be impacted after datctype&datcollate "C"->"en_US.UTF-8" change? Encoding has always been UTF8, btw. postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- mydb | myuser | UTF8 | C | C |
В списке pgsql-general по дате отправления: