Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem. initdb in C locale, then
start postmaster with LANG=en_US.UTF-8 in its environment. Then:
z1=# create language plperl;
CREATE LANGUAGE
z1=# select 'enum.server_task_log.status.RUNNING'::varchar <
'enum.server_task_log.status.keys'::varchar;
?column?
----------
t -- correct result for C locale
(1 row)
z1=# \c z1
You are now connected to database "z1".
z1=# SET check_function_bodies = false;
SET
z1=# create or replace function perlf() returns text as $$
z1$# return 'foo';
z1$# $$ language plperl;
CREATE FUNCTION
z1=# select 'enum.server_task_log.status.RUNNING'::varchar <
'enum.server_task_log.status.keys'::varchar;
?column?
----------
f -- WRONG result for C locale
(1 row)
Unfortunately we have not fixed this on Windows. I have confirmed the
effect on 8.1.1, and I still see this effect on HEAD. We have fixed the
check_function_bodies bit, but if that is on, or if I call a plperl
func, I get the bad result shown above.
The log message from the commit that was supposed to fix this says:
Arrange to set the LC_XXX environment variables to match our locale
setup. This protects against undesired changes in locale behavior
if someone carelessly does setlocale(LC_ALL, "") (and we know who
you are, perl guys).
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.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
