Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
От | Joe Conway |
---|---|
Тема | Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG |
Дата | |
Msg-id | ec6fa20d-e691-198a-4a13-e761771b9dec@joeconway.com обсуждение исходный текст |
Ответ на | Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
|
Список | pgsql-hackers |
On 6/22/23 03:26, Heikki Linnakangas wrote: > On 21/06/2023 01:02, Joe Conway wrote: >> On 6/19/23 19:30, Heikki Linnakangas wrote: >>> I think we should call "uselocale(LC_GLOBAL_LOCALE)" immediately after >>> returning from the perl interpreter, instead of before setlocale() >>> calls, if we want all Postgres code to run with the global locale. Not >>> sure how much performance overhead that would have. >> >> I don't see how that is practical, or at least it does not really >> address the issue. I think any loaded shared library could cause the >> same problem by running newlocale() + uselocale() on init. Perhaps I >> should go test that theory though. > > Any shared library could do that, that's true. Any shared library could > also call 'chdir'. But most shared libraries don't. I think it's the > responsibility of the extension that loads the shared library, plperl in > this case, to make sure it doesn't mess up the environment for the > postgres backend. Ok, fair enough. The attached fixes all of the issues raised on this thread by specifically patching plperl. 8<------------ create or replace function finnish_to_number() returns numeric as $$ select to_number('1,23', '9D99') $$ language sql set lc_numeric to 'fi_FI.utf8'; pl_regression=# show lc_monetary; lc_monetary ------------- C (1 row) DO LANGUAGE 'plperlu' $$ use POSIX qw(setlocale LC_NUMERIC); use locale; setlocale LC_NUMERIC, "fi_FI.utf8"; $n = 5/2; # Assign numeric 2.5 to $n spi_exec_query('SELECT finnish_to_number()'); # Locale-dependent conversion to string $a = " $n"; # Locale-dependent output elog(NOTICE, "half five is $n"); $$; NOTICE: half five is 2,5 DO set lc_messages ='sv_SE.UTF8'; this prints syntax error in Swedish; FEL: syntaxfel vid eller nära "this" LINE 1: this prints syntax error in Swedish; ^ set lc_messages ='en_GB.utf8'; this *should* print syntax error in English; ERROR: syntax error at or near "this" LINE 1: this *should* print syntax error in English; ^ set lc_monetary ='sv_SE.UTF8'; SELECT 12.34::money AS price; price ---------- 12,34 kr (1 row) set lc_monetary ='en_GB.UTF8'; SELECT 12.34::money AS price; price -------- £12.34 (1 row) set lc_monetary ='en_US.UTF8'; SELECT 12.34::money AS price; price -------- $12.34 (1 row) 8<------------ This works correctly from what I can see -- tested against pg16beta1 on Linux Mint with perl v5.34.0 as well as against pg15.2 on RHEL 7 with perl v5.16.3. Although I have not looked yet, presumably we could have similar problems with plpython. I would like to get agreement on this approach against plperl before diving into that though. Thoughts? -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: