Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
Дата
Msg-id c9ba493c-63bb-4c32-d7dc-6f5862a29bb1@iki.fi
обсуждение исходный текст
Ответ на Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG  (Joe Conway <mail@joeconway.com>)
Ответы Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Joseph Koshakow
Дата:
Сообщение: Re: DecodeInterval fixes
Следующее
От: Thomas Munro
Дата:
Сообщение: CI speed improvements for FreeBSD