From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Tristan Partin <tristan(at)neon(dot)tech>, gdo(at)leader(dot)it, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG |
Date: | 2023-06-19 23:30:50 |
Message-ID: | fb4f7abd-6c66-1a35-feea-115d44e6c02a@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-06-20 01:22:19 | Re: BUG #17949: Adding an index introduces serialisation anomalies. |
Previous Message | Tom Lane | 2023-06-19 20:59:15 | Re: BUG #17978: Unexpected error: "wrong varnullingrels (b) (expected (b 5)) for Var 6/2" triggered by JOIN |
From | Date | Subject | |
---|---|---|---|
Next Message | Tristan Partin | 2023-06-19 23:49:05 | Re: Make pgbench exit on SIGINT more reliably |
Previous Message | Peter Geoghegan | 2023-06-19 23:28:38 | Optimizing "boundary cases" during backward scan B-Tree index descents |