Peter Eisentraut wrote:
> Heikki Linnakangas wrote:
>> Peter Eisentraut wrote:
>>> Which raises yet another question, why CTYPE and COLLATE have to be
>>> hardcoded settings and catalog columns instead of being stored in
>>> datconfig as database-startup-only settings?
>>
>> Because changing CTYPE or COLLATE in an existing database would render
>> indexes broken.
>>
>> Perhaps we could've put them in datconfig, and forbidden changing them
>> after CREATE DATABASE. Then again, encoding is a similar setting too,
>> and that's stored in a catalog column.
>
> Yeah, it's a tricky case somewhere in between all the facilities that we
> already have.
>
> I notice in the documentation that the createdb --lc-ctype sets the
> lc_ctype setting for the database, but the corresponding parameter for
> CREATE DATABASE is CTYPE, but the global GUC setting is lc_ctype. Should
> that be more consistent?
Hmm, I remember I pondered for a long time if it should be COLLATE and
CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or
some other collation implementation, the association with LC_*
environment variables becomes misleading.
Being consistent would be nice, though.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
