Re: 8.4 open items list

Bruce Momjian wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> Tom Lane wrote:
>>>> Personally I think the naming decision is close enough to be a coin
>>>> toss, and so either choice is fine with me.  However, I think it is
>>>> Clearly Unacceptable for createdb's switches to be spelled differently
>>>> than the underlying SQL command's options.  So it's not really "let's
>>>> not change this" but "which one do you consider it more important to not
>>>> change"?
>>> pgAdmin uses the SQL commands, not the external commands. IIRC the only
>>> external commands that are used are pg_dump[all], pg_restore, pg_ctl and
>>> initdb. Is initdb on the list of tools that might be changed?
>> Hm, that's a good point.  initdb has these switches (and has had 'em for
>> a good long time):
>>
>>       --locale=LOCALE       set default locale for new databases
>>       --lc-collate=, --lc-ctype=, --lc-messages=LOCALE
>>       --lc-monetary=, --lc-numeric=, --lc-time=LOCALE
>>                             set default locale in the respective category for
>>                             new databases (default taken from environment)
>>       --no-locale           equivalent to --locale=C
>>
>> So createdb is consistent with longstanding history in initdb, and
>> that seems to mean that we should leave it alone and change
>> CREATE DATABASE to match (modulo underscore instead of dash).
> 
> Agreed, I see them back to Postgres 8.0:
> 
>     8.0/pgsql/src/bin/initdb/initdb.c:
>     printf(_(" --lc-collate, --lc-ctype, --lc-messages=LOCALE\n"

Ok, it looks like we have a consensus on changing the CREATE DATABASE 
options to LC_COLLATE and LC_CTYPE.

Now, what about the idea of providing a shorthand LOCALE='foo', 
mirroring --locale=foo initdb option? It seems like a good idea, because 
you almost never want to set LC_COLLATE and LC_CTYPE differently. If we 
do that, should LOCALE=foo also imply a per-database lc_messages, 
lc_monetary, lc_numeric and lc_time settings? It seems like it should 
for the sake of consistency.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com