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  ("Tristan Partin" <tristan@neon.tech>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Allow ordered partition scans in more cases
Следующее
От: Pavel Luzanov
Дата:
Сообщение: Re: psql: Add role's membership options to the \du+ command