Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) |
Date | |
Msg-id | 43C063AD.1030101@dunslane.net Whole thread Raw |
In response to | Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) (Andrew Dunstan <andrew@dunslane.net>) |
Responses |
Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
|
List | pgsql-hackers |
Andrew Dunstan wrote: > > > Tom Lane wrote: > >> Andrew Dunstan <andrew@dunslane.net> writes: >> >> >>> However, to the best of my knowledge, Windows does NOT consult the >>> environment when set_locale is called. ISTM we probably need to call >>> set_locale ourselves on Windows with the desired values. >>> >> >> >> We already do, during process startup. The question becomes where the >> heck is Perl looking for the locale information, when on Windows? >> >> > > The Windows docs at > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_setlocale.2c_._wsetlocale.asp > say: > > |setlocale( LC_ALL, "" );| > Sets the locale to the default, which is the user-default ANSI code > page obtained from the operating system. > > Does libperl call this only at interpreter startup? If so, maybe we > should probably save out the settings and then restore them after the > interpreter has started. > > After some analysis of perl's locale.c, I came up with the attached patch, which seems to cure the previously observed problem on my Windows box. The questions are: a) is this an acceptable solution, and b) should we do this for all the LC_* settings (on Windows at least)? Especially, should we do it for LC_CTYPE? cheers andrew Index: plperl.c =================================================================== RCS file: /projects/cvsroot/pgsql/src/pl/plperl/plperl.c,v retrieving revision 1.98 diff -c -r1.98 plperl.c *** plperl.c 29 Dec 2005 14:28:31 -0000 1.98 --- plperl.c 8 Jan 2006 00:49:57 -0000 *************** *** 45,50 **** --- 45,51 ---- #include <ctype.h> #include <fcntl.h> #include <unistd.h> + #include <stdlib.h> /* postgreSQL stuff */ #include "commands/trigger.h" *************** *** 60,65 **** --- 61,72 ---- extern DLLIMPORT bool check_function_bodies; /* perl stuff */ + + /* prevent perl headers from hijacking stdio and lots of other stuff */ + #ifdef WIN32 + #define WIN32IO_IS_STDIO + #endif + #include "EXTERN.h" #include "perl.h" #include "XSUB.h" *************** *** 263,268 **** --- 270,297 ---- "", "-e", PERLBOOT }; + + char lang_buf[256], col_buf[256] ; + char * env_entry; + + lang_buf[0] = col_buf[0] = '\0'; + + env_entry= getenv("LANG"); + + if (env_entry && strlen(env_entry) > 0) + { + snprintf(lang_buf,256, "LANG=%s", env_entry); + unsetenv("LANG"); + } + + env_entry = getenv("LC_COLLATE"); + + if (env_entry && strlen(env_entry) > 0) + { + snprintf(col_buf,256,"LC_COLLATE=%s",env_entry); + unsetenv("LC_COLLATE"); + } + plperl_interp = perl_alloc(); if (!plperl_interp) elog(ERROR, "could not allocate Perl interpreter"); *************** *** 272,277 **** --- 301,311 ---- perl_run(plperl_interp); plperl_proc_hash = newHV(); + + if (strlen(lang_buf) > 0) + putenv(lang_buf); + if(strlen(col_buf) > 0) + putenv(col_buf); }
pgsql-hackers by date: