Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander <mag...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
