Re: [GENERAL] Changing collate & ctype for an existing database - Mailing list pgsql-general

From rihad
Subject Re: [GENERAL] Changing collate & ctype for an existing database
Date
Msg-id bd55a74f-cb0b-49fd-1f70-b3bbe4729b72@mail.ru
Whole thread Raw
In response to Re: [GENERAL] Changing collate & ctype for an existing database  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Changing collate & ctype for an existing database  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: rihad
Date:
Subject: Re: [GENERAL] Changing collate & ctype for an existing database
Next
From: "Zhu, Joshua"
Date:
Subject: Re: [GENERAL] BDR node removal and rejoin