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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
