Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)

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