I've mentioned a while ago that I wanted to make the --enable-locale
switch the default (and remove the switch), and make the choice of
locale-awareness a run-time choice. Here is how that might work. I've
already explained how I plan to get around the performance problems, so
this will just focus on the user interface.
We currently have two kinds of locale categories: Those that must be
fixed at initdb-time and those that may be changed at run-time.
I suggest that initdb always defaults its locales to C and that we
provide command line options to set a different locale. E.g.,
initdb --lc-collate=en_US
This makes the change transparent for those who like the C locale. It is
also much clearer than figuring out which of LANG, LC_COLLATE, LC_ALL will
get in your way.
Personally, I also find it better to separate the locale settings in your
login account meant for interactive use from those meant for PostgreSQL
servers. In other words, if I'm the "postgres" account and administering
a bunch of databases I'd still like to set LC_ALL=de_DE so all the shell
commands print their things formatted right, and I don't want to change
this every time I start a server from within that account.
In particular, I'd like the following set of options:
--lc-collate
--lc-ctype
--locale (allows specifying all in one, but may be overridden by specific options)
It might actually work to say
initdb --locale=''
to force inherting the settings from the environment.
In the post-initdb stage, we'd add a bunch of GUC variables, such as
lc_numeric
lc_monetary
lc_time
locale
These all default to "C". For a start we'd make them fixed for the
life-time of the postmaster, but we could evaluate other options later.
This again makes this change hidden for users that didn't use locale
support. Also, it prevents accidentally changing the locale when you
(or someone else) fiddle with your environment variables.
Note that you get the same kind of command line options as in initdb:
--lc-numeric, --locale, etc. You can also run SHOW lc_numeric to see
what's going on.
Comments?
--
Peter Eisentraut peter_e@gmx.net
