Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
Date
Msg-id c9ba493c-63bb-4c32-d7dc-6f5862a29bb1@iki.fi
Whole thread Raw
In response to Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG  (Joe Conway <mail@joeconway.com>)
Responses Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
List pgsql-hackers
On 27/08/2023 16:41, Joe Conway wrote:
> On 8/15/23 10:40, Heikki Linnakangas wrote:
>> If multiple interpreters are used, is the single perl_locale_obj
>> variable still enough? Each interpreter can have their own locale I believe.
> 
> So in other words plperl and plperlu both used in the same query? I
> don't see how we could get from one to the other without going through
> the outer "postgres" locale first. Or are you thinking something else?

I think you got that it backwards. 'perl_locale_obj' is set to the perl 
interpreter's locale, whenever we are *outside* the interpreter.

This crashes with the patch:

postgres=# DO LANGUAGE plperlu
$function$
    use POSIX qw(setlocale LC_NUMERIC);
    use locale;

    setlocale LC_NUMERIC, "sv_SE.utf8";
$function$;
DO
postgres=# do language plperl $$ $$;
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

I was going to test using plperl and plperl in the same session and 
expected the interpreters to mix up the locales they use. Maybe the 
crash is because of something like that, although I didn't expect a 
crash, just weird confusion on which locale is used.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Joseph Koshakow
Date:
Subject: Re: DecodeInterval fixes
Next
From: Thomas Munro
Date:
Subject: CI speed improvements for FreeBSD