Tom Lane wrote:
>Michael Paesold <mpaesold@gmx.at> 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
localebehavior 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
probablyneed to call set_locale ourselves on Windows with the desired values.
cheers
andrew