[PATCHES] Win32 NLS
Hi! Working the NLS stuff on win32. Considering I know very little about this part (don't use it myself, never coded around in it), perhaps someone else can shed some light? PostgreSQL responds correctly to whatever the LC_MESSAGES environment variable is set to upon startup of postgresql - I get my error messages in swedish, english, german or whatever depending on that. However, postgresql.conf does not load with the error message: FATAL: invalid value for parameter lc_messages: EN This goes for whatever I set lc_messages to, including all the combinations that work when set in the environment variable. If I comment it out completely from the config file, things appear to work with the locale picked up from the environment. (The error msg of course only shows up when NLS is enabled in configure) Some quick tracking-down of this shows that the code on line 80-82 of pg_locale.c: save = setlocale(category, NULL); if (!save) return NULL;/* won't happen, we hope */ *does* return NULL... Now, I really don't know anything about the setlocale() integration, but from the MSDN documentation (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/ html/_crt_setlocale.2c_._wsetlocale.asp) doesn't even list LC_MESSAGES as a valid identifier. My bet is that's why it returns NULL on LC_MESSAGES. Also, some googling lead me to this: http://www.haible.de/bruno/gettext-FAQ.html#windows_woe32 Which appears to suggest that we should change the locale using putenv() etc, and not using setlocale() at all... Because setlocale() does not support LC_MESSAGES, probably. 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. Comments? (There is also a patch for initdb required to work on win32 when compiled with NLS enabled, but this is the start...) //Magnus win32nls.patch Description: win32nls.patch ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Win32 NLS
Magnus Hagander wrote: Which appears to suggest that we should change the locale using putenv() etc, and not using setlocale() at all... Because setlocale() does not support LC_MESSAGES, probably. This cannot possibly work. putenv() doesn't change any locale. The environment variables only serve as a default when you call setlocale() without an actual locale value. But to enable any locale, you always need to call setlocale() somehow, somewhere. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Win32 NLS
Which appears to suggest that we should change the locale using putenv() etc, and not using setlocale() at all... Because setlocale() does not support LC_MESSAGES, probably. This cannot possibly work. putenv() doesn't change any locale. The environment variables only serve as a default when you call setlocale() without an actual locale value. But to enable any locale, you always need to call setlocale() somehow, somewhere. That was my first thought, too. But it *does* appear to work. With this patch, I can change lc_messages from environment-before-startup, from postgresql.conf or using set lc_messages='foo'. The only main thing I see as being wrong is that it cannot check if the specified messages were incorrect. If I literally set it to foo, I get english without getting any error/warning. Clearly they don't just serve as defaults on win32. That's the only conclusion I can draw from the fact that this works, and from the questions in the FAQ referenced. See also for example http://lists.gnu.org/archive/html/bug-gnu-utils/2004-02/msg00091.html //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
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
[PATCHES] windows progname / regression fixes
Attached are 2 patches and one additional alternative contrib regression test file (for cube). The patches fix a misleading message in pg_regress.sh, and strip the .exe suffix from the result of get_progname() as previously discussed. This lets us get much further with contrib regression tests - there are 2 remaining issues preventing a clean run - one odd one in the seg module and a path issue in tsearch2. I am looking into these. (Why am I bothered with all this? Because I want the buildfarm system to run on Windows). One odd thing I have noticed in testing, is that dropping the regression database takes a *very* long time, especially after the third or fourth go, and I see messages about not being able to remove the directory, which means rmtree() is failing somehow. cheers andrew -- -- Test cube datatype -- -- -- first, define the datatype. Turn off echoing so that expected file -- does not depend on contents of cube.sql. -- \set ECHO none psql:cube.sql:10: NOTICE: type cube is not yet defined DETAIL: Creating a shell type definition. psql:cube.sql:15: NOTICE: argument type cube is only a shell -- -- testing the input and output functions -- -- Any number (a one-dimensional point) SELECT '1'::cube AS cube; cube -- (1) (1 row) SELECT '-1'::cube AS cube; cube -- (-1) (1 row) SELECT '1.'::cube AS cube; cube -- (1) (1 row) SELECT '-1.'::cube AS cube; cube -- (-1) (1 row) SELECT '.1'::cube AS cube; cube --- (0.1) (1 row) SELECT '-.1'::cube AS cube; cube (-0.1) (1 row) SELECT '1.0'::cube AS cube; cube -- (1) (1 row) SELECT '-1.0'::cube AS cube; cube -- (-1) (1 row) SELECT '1e27'::cube AS cube; cube -- (1e+027) (1 row) SELECT '-1e27'::cube AS cube; cube --- (-1e+027) (1 row) SELECT '1.0e27'::cube AS cube; cube -- (1e+027) (1 row) SELECT '-1.0e27'::cube AS cube; cube --- (-1e+027) (1 row) SELECT '1e+27'::cube AS cube; cube -- (1e+027) (1 row) SELECT '-1e+27'::cube AS cube; cube --- (-1e+027) (1 row) SELECT '1.0e+27'::cube AS cube; cube -- (1e+027) (1 row) SELECT '-1.0e+27'::cube AS cube; cube --- (-1e+027) (1 row) SELECT '1e-7'::cube AS cube; cube -- (1e-007) (1 row) SELECT '-1e-7'::cube AS cube; cube --- (-1e-007) (1 row) SELECT '1.0e-7'::cube AS cube; cube -- (1e-007) (1 row) SELECT '-1.0e-7'::cube AS cube; cube --- (-1e-007) (1 row) SELECT '1e-700'::cube AS cube; cube -- (0) (1 row) SELECT '-1e-700'::cube AS cube; cube -- (0) (1 row) SELECT '1234567890123456'::cube AS cube; cube - (1.23456789012346e+015) (1 row) SELECT '+1234567890123456'::cube AS cube; cube - (1.23456789012346e+015) (1 row) SELECT '-1234567890123456'::cube AS cube; cube -- (-1.23456789012346e+015) (1 row) SELECT '.1234567890123456'::cube AS cube; cube - (0.123456789012346) (1 row) SELECT '+.1234567890123456'::cube AS cube; cube - (0.123456789012346) (1 row) SELECT '-.1234567890123456'::cube AS cube; cube -- (-0.123456789012346) (1 row) -- simple lists (points) SELECT '1,2'::cube AS cube; cube (1, 2) (1 row) SELECT '(1,2)'::cube AS cube; cube (1, 2) (1 row) SELECT '1,2,3,4,5'::cube AS cube; cube - (1, 2, 3, 4, 5) (1 row) SELECT '(1,2,3,4,5)'::cube AS cube; cube - (1, 2, 3, 4, 5) (1 row) -- double lists (cubes) SELECT '(0),(0)'::cube AS cube; cube -- (0) (1 row) SELECT '(0),(1)'::cube AS cube; cube - (0),(1) (1 row) SELECT '[(0),(0)]'::cube AS cube; cube -- (0) (1 row) SELECT '[(0),(1)]'::cube AS cube; cube - (0),(1) (1 row) SELECT '(0,0,0,0),(0,0,0,0)'::cube AS cube; cube -- (0, 0, 0, 0) (1 row) SELECT '(0,0,0,0),(1,0,0,0)'::cube AS cube; cube --- (0, 0, 0, 0),(1, 0, 0, 0) (1 row) SELECT '[(0,0,0,0),(0,0,0,0)]'::cube AS cube; cube -- (0, 0, 0, 0) (1 row) SELECT '[(0,0,0,0),(1,0,0,0)]'::cube AS cube; cube --- (0, 0, 0, 0),(1, 0, 0, 0) (1 row) -- invalid input: parse errors SELECT ''::cube AS cube; ERROR: bad cube representation DETAIL: syntax error at end of input SELECT 'ABC'::cube AS cube; ERROR: bad cube representation DETAIL: syntax error at or near A SELECT '()'::cube AS cube; ERROR: bad cube representation DETAIL: syntax error at or near ) SELECT '[]'::cube AS cube; ERROR: bad cube representation DETAIL: syntax error at or near ] SELECT '[()]'::cube AS cube; ERROR: bad cube representation
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
Re: [PATCHES]Update postgres-zh_TW.po for 8.0
Zhenbang Wei wrote: This time msgfmt says ok. Thanks. Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] (Turkish)New translation: pg_config
Devrim GUNDUZ wrote: http://www.gunduz.org/postgresql/translation/PostgreSQL-8.0/pg_config -tr.pot Could you please apply it? Done. Btw., you have the file names wrong. The translated files should have a .po extension. .pot is an untranslated PO template. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] (Turkish)New translation: pg_config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Sun, 17 Oct 2004, Peter Eisentraut wrote: Btw., you have the file names wrong. The translated files should have a .po extension. .pot is an untranslated PO template. Ok, thanks. I've updated them on my side and my cvs server. Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBcuDrtl86P3SPfQ4RAshyAKCdFwA8fErFDPg1GMkZTJSobNyEqQCdE4/Y UZQYb5GoDYEh2gGEXaXVli0= =qp6z -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] additional GCC warning flags
This patch adds code to configure to check if GCC supports the
following warning flags: -Wdeclaration-after-statement (GCC 3.4+),
-Wold-style-definition (GCC 3.4+), and -Wendif-labels (GCC 3.3+). Any of
these options that are supported by $CC are added to $CFLAGS. The patch
also removes -Wmissing-declarations from the default CFLAGS, on the
grounds that it is (I believe) redundant when -Wmissing-prototypes is
also specified.
(I didn't mention -Wendif-labels in my mail to -hackers, but it should
be pretty innocuous: Warn whenever an #else or an #endif are followed
by text.)
This patch updates configure.in and configure (I re-ran autoconf 2.53).
It doesn't introduce any additional warning messages locally (Linux, GCC
3.4), but might do so on some platforms (the code in src/port/ is likely
to trigger some warnings, I think). Because of that, I think it is
probably best to save this for 8.1
-Neil
Index: configure
===
RCS file: /var/lib/cvs/pgsql/configure,v
retrieving revision 1.402
diff -c -r1.402 configure
*** configure 15 Oct 2004 05:10:53 - 1.402
--- configure 18 Oct 2004 03:56:37 -
***
*** 2497,2502
--- 2497,2676
CFLAGS=$CFLAGS $pgac_cv_prog_cc_no_strict_aliasing
fi
+ # Check if we're using a recent version of GCC; if so, enable some
+ # additional warning flags
+ echo $as_me:$LINENO: checking if $CC supports -Wdeclaration-after-statement 5
+ echo $ECHO_N checking if $CC supports -Wdeclaration-after-statement... $ECHO_C 6
+ if test ${pgac_cv_prog_cc_warn_decl_after_stmt+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ pgac_save_CFLAGS=$CFLAGS
+ pgac_cv_prog_cc_warn_decl_after_stmt=no
+ if test $GCC = yes; then
+ CFLAGS=$pgac_save_CFLAGS -Wdeclaration-after-statement
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+
+ #ifdef F77_DUMMY_MAIN
+ # ifdef __cplusplus
+ extern C
+ # endif
+int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+
+ ;
+ return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo $as_me:$LINENO: \$ac_compile\) 5
+ (eval $ac_compile) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ pgac_cv_prog_cc_warn_decl_after_stmt=yes
+ break
+ else
+ echo $as_me: failed program was: 5
+ cat conftest.$ac_ext 5
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+
+ CFLAGS=$pgac_save_CFLAGS
+
+ fi
+ echo $as_me:$LINENO: result: $pgac_cv_prog_cc_warn_decl_after_stmt 5
+ echo ${ECHO_T}$pgac_cv_prog_cc_warn_decl_after_stmt 6
+
+ if test $pgac_cv_prog_cc_warn_decl_after_stmt = yes; then
+ CFLAGS=$CFLAGS -Wdeclaration-after-statement
+ fi
+ echo $as_me:$LINENO: checking if $CC supports -Wold-style-definition 5
+ echo $ECHO_N checking if $CC supports -Wold-style-definition... $ECHO_C 6
+ if test ${pgac_cv_prog_cc_warn_old_style_definition+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ pgac_save_CFLAGS=$CFLAGS
+ pgac_cv_prog_cc_warn_old_style_definition=no
+ if test $GCC = yes; then
+ CFLAGS=$pgac_save_CFLAGS -Wold-style-definition
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+
+ #ifdef F77_DUMMY_MAIN
+ # ifdef __cplusplus
+ extern C
+ # endif
+int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+
+ ;
+ return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo $as_me:$LINENO: \$ac_compile\) 5
+ (eval $ac_compile) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ pgac_cv_prog_cc_warn_old_style_definition=yes
+ break
+ else
+ echo $as_me: failed program was: 5
+ cat conftest.$ac_ext 5
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+
+ CFLAGS=$pgac_save_CFLAGS
+
+ fi
+ echo $as_me:$LINENO: result: $pgac_cv_prog_cc_warn_old_style_definition 5
+ echo ${ECHO_T}$pgac_cv_prog_cc_warn_old_style_definition 6
+
+ if test $pgac_cv_prog_cc_warn_old_style_definition = yes; then
+ CFLAGS=$CFLAGS -Wold-style-definition
+ fi
+ echo $as_me:$LINENO: checking if $CC supports -Wendif-labels 5
+ echo $ECHO_N checking if $CC supports -Wendif-labels... $ECHO_C 6
+ if test ${pgac_cv_prog_cc_warn_endif_labels+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ pgac_save_CFLAGS=$CFLAGS
+ pgac_cv_prog_cc_warn_endif_labels=no
+ if test $GCC = yes; then
+ CFLAGS=$pgac_save_CFLAGS -Wendif-labels
+ cat conftest.$ac_ext _ACEOF
+ #line $LINENO configure
+ #include confdefs.h
+
+ #ifdef F77_DUMMY_MAIN
+ #
