Re: Changing collate & ctype for an existing database

From: rihad <rihad(at)mail(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Changing collate & ctype for an existing database
Date: 2017-07-13 05:41:42
Message-ID: a15ccaf0-6a32-05be-f3ab-1c308130584b@mail.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 07/12/2017 11:25 PM, Tom Lane wrote:
> rihad <rihad(at)mail(dot)ru> writes:
>> 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?
> Yes, as even minimal testing would have told you. C sort order is
> more case-sensitive, for instance.
>
> regards, tom lane
> .
>
Thanks. It would be great if initdb didn't assume an implicit encoding,
to prevent such fundamental configuration mistakes in the future. More
often than not collation/ctype settings of an ssh login session used to
run initdb aren't what must be used to set up the cluster. It'd be great
if initdb didn't go any further if not provided with an explicit
encoding. The error message would require the user to think twice before
proceeding, and to read up on the matter. Explicit is better than
implicit, as the old saying goes :)

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2017-07-13 06:58:34 Re: BDR node removal and rejoin
Previous Message Jeff Janes 2017-07-13 03:26:56 Monitoring of a hot standby with a largely idle master