Re: [PATCHES] [pgsql-hackers-win32] Win32 NLS
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] Win32 NLS
Magnus Hagander [EMAIL PROTECTED] writes: Test program attached, results below. It returns NULL for whatever I try with LC_MESSAGES. It looks like LC_MESSAGES just plain does not work on Windows. I did some googling and found some pages suggesting this, for instance http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_setlocale.2c_._wsetlocale.asp The patch you suggest looks remarkably ugly; in particular it is generally unsafe to pass a local variable to putenv. Perhaps that does not matter on Windows but I wonder whether the putenv part couldn't just be dropped. And why bother with ZeroMemory? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-hackers-win32] Win32 NLS
Test program attached, results below. It returns NULL for whatever I try with LC_MESSAGES. It looks like LC_MESSAGES just plain does not work on Windows. I did some googling and found some pages suggesting this, for instance http://msdn.microsoft.com/library/default.asp?url=/library/en-u s/vclib/html/_crt_setlocale.2c_._wsetlocale.asp Yes, that's exactly the link I had in my original mail. The patch you suggest looks remarkably ugly; in particular it is generally unsafe to pass a local variable to putenv. Perhaps that does not matter on Windows but I wonder whether the putenv part couldn't just be dropped. I got that from the gettext FAQ. The problem is that MSVCRT caches the environment, and that's what you access using getenv() and putenv(). And this is what gettext uses internally. The API call is to change the actual process environment. That's why you need both. As for the dangers of passing a local variable - there is nothing abot that in the putenv documentation on MSDN. So I would assume it's safe on windows. And why bother with ZeroMemory? Oops. that's a leftover from some previous hacking. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-hackers-win32] Win32 NLS
Magnus Hagander [EMAIL PROTECTED] writes: Attached is a patch with adds a environment variable based version of locale_messages_assign(). It's not a pretty solution, but I think it's probably necessary. Applied with minor cleanup. I'm still concerned about the order-of-operations issue, but some desultory experimentation on Linux (Fedora Core 3) did not find any cases where setlocale(LC_MESSAGES) would fail because of a contradictory LC_CTYPE setting, so maybe that theory is all wet. Still it seems there is *something* fishy going on, given the number of reports we've seen. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
