Tom Lane writes:
> If I follow this correctly, the behavior would be that PG would not pay
> attention to *any* LC_xxx environment variables? Although I agree with
> that principle in the abstract, it bothers me that PG will be out of
> step with every single other locale-using program in the Unix world.
During earlier discussions people had objected to enabling locale support
by default on the grounds that it is very hard to follow which locale is
getting activated when. Especially from Japan I heard that a lot of
people have some locale settings in their environment, but that most
locales are unsuitable ("broken") for use in the PostgreSQL server. So
this approach would keep the behavior backward compatible with the
--disable-locale case.
Here's a possible compromise for the postmaster:
We let initdb figure out what locales the user wants and then not only
initialize pg_control appropriately, but also write the run-time
changeable categories into the postgresql.conf file. That way, the
postmaster executable could still consult the LC_* variables, but in the
common case it would just be overridden when the postgresql.conf file is
read.
This way we also hide the details of what locale category gets what
treatment from users that only want one locale for all categories and
don't want to change it. Futhermore it all but eliminates the problem I'm
concerned about that the locale may accidentally be changed when the
postmaster is restarted.
How does initdb figure out what locale is wanted? I agree it makes sense
to use the setting in the environment, because in many cases the database
will want to use the same locale as everything else on the system. We
could provide a flag --no-locale, which sets all locale categories to "C",
as a clear and simple way to turn this off.
--
Peter Eisentraut peter_e@gmx.net
