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 fb4f7abd-6c66-1a35-feea-115d44e6c02a@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 18/06/2023 21:27, Joe Conway wrote:
> I have proposed a targeted fix that I believe is safe to backpatch --
> attached.
> 
> IIUC, Tom was +1, but Heikki was looking for a more general solution.
> 
> My issue with the more general solution is that it will likely be too
> invasive to backpatch, and at the moment at least, there are no other
> confirmed bugs related to all of this (even if the current code is more
> fragile than we would prefer).

Ok, I agree switching to uselocale() everywhere is too much to 
backpatch. We should consider it for master though.

With the patch you're proposing, do we now have a coding rule that you 
must call "uselocale(LC_GLOBAL_LOCALE)" before every and any call to 
setlocale()? If so, you missed a few spots: pg_perm_setlocale, 
pg_bind_textdomain_codeset, and cache_locale_time.

The current locale affects a lot of other things than localeconv() 
calls. For example, LC_MESSAGES affects all strerror() calls. Do we need 
to call "uselocale(LC_GLOBAL_LOCALE)" before all possible strerror() 
calls too?

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 just found out about perl's "switch_to_global_locale" function 
(https://perldoc.perl.org/perlapi#switch_to_global_locale). Should we 
use that?

Testing the patch, I bumped into this:

postgres=# 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';
CREATE FUNCTION
postgres=# 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()');

$a = " $n"; # Locale-dependent conversion to string
elog(NOTICE, "half five is $n");       # Locale-dependent output
$$;
NOTICE:  half five is 2,5
DO
postgres=# select to_char(now(), 'Day');
WARNING:  could not determine encoding for locale "en_GB.UTF-8": codeset 
is "ANSI_X3.4-1968"
   to_char
-----------
  Tuesday
(1 row)

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




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Optimizing "boundary cases" during backward scan B-Tree index descents
Next
From: "Tristan Partin"
Date:
Subject: Re: Make pgbench exit on SIGINT more reliably