Re: per-database locale: createdb switches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: per-database locale: createdb switches
Date: 2009-01-13 17:02:57
Message-ID: 27938.1231866177@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Heikki Linnakangas wrote:
>> 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.

> I think consistency could be reached by renaming the GUC setting to
> ctype.

I think this is a bad idea, particularly if you also rename the other
GUC to COLLATE (which is a reserved word that we're going to have to
implement someday). People know what LC_CTYPE and LC_COLLATE do,
at least if they've heard of Unix locale support at all (and if not
they can google those names successfully).

If we want consistency then the right answer is to rename the *new*
things to lc_xxx, not break compatibility on the names of the
existing things.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-01-13 17:16:28 Re: [BUGS] Status of issue 4593
Previous Message Kevin Grittner 2009-01-13 16:59:52 Re: [BUGS] Status of issue 4593