"Magnus Hagander" <mha@sollentuna.net> writes:
> Tried that too. Tried a whole lot of combinations of both unix style
> (sv_SE, sv, se, se_sv for example) and windows style (Swedish.Sweden,
> Sweden.Swedish, Swedish.Sweden.1252, etc etc). *it never works*. It
> *does work* if I set it as an environment variable.
I tried setting a breakpoint at setlocale() and tracing through
postmaster startup. I now realize that we have a rather fundamental
problem, which is that the startup sequence is essentially:
setlocale(LC_COLLATE, "");
setlocale(LC_CTYPE, "");
// other uninteresting setlocales...
setlocale(LC_MESSAGES, value_from_config_file);
// and ditto for the other LC values in the config file
setlocale(LC_COLLATE, value_from_pg_control);
setlocale(LC_CTYPE, value_from_pg_control);
That is, postgresql.conf is read before we have located and read
pg_control. Therefore, if the LC_CTYPE value specified in pg_control
is different from whatever happens to be implied by the postmaster's
current environment, it is entirely possible for the set of allowed
LC_MESSAGES values during the initial config file read to be different
from the set that would be legal later. I am supposing here that
setlocale() may reject LC_MESSAGES values that imply a character set
different from that implied by LC_CTYPE.
Magnus, can you try a quick standalone test program to see if Windows'
setlocale seems to act that way? The FAQ you pointed at implies that
GNU gettext has some issues in this area, but it doesn't say outright
that the setlocale function itself fails.
If this is the problem then it might explain the various past complaints
we've gotten about being unable to set LC_MESSAGES on some operating
systems (OS X at least). My thoughts about fixing it are leaning
towards postponing processing of the LC_xxx config values until after
we've read pg_control, but that seems like a mess :-(
regards, tom lane
