From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
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-18 18:27:13 |
Message-ID: | ac52326b-874b-372f-220c-60b424a9a833@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 6/12/23 17:28, Joe Conway wrote:
> On 6/12/23 10:44, Joe Conway wrote:
>> 1/ how do we fix the misbehavior reported due to libperl in existing
>> stable branches
>
> <snip>
>
>> I was mostly trying to concentrate on #1, but 2 & 3 are worthy of
>> discussion.
>
> Hmm, browsing through the perl source I came across a reference to this
> (from https://perldoc.perl.org/perllocale)
>
> ---------------
> PERL_SKIP_LOCALE_INIT
>
> This environment variable, available starting in Perl v5.20, if set
> (to any value), tells Perl to not use the rest of the environment
> variables to initialize with. Instead, Perl uses whatever the current
> locale settings are. This is particularly useful in embedded
> environments, see "Using embedded Perl with POSIX locales" in perlembed.
> ---------------
>
> Seems we ought to be using that.
Turns out that that does nothing useful as far as I can tell.
So I am back to proposing the attached against pg16beta1, to be
backpatched to pg11.
Since much of the discussion happened on pgsql-bugs, the background
summary for hackers is this:
When plperl is first loaded, the init function eventually works its way
to calling Perl_init_i18nl10n(). In versions of perl >= 5.20, that ends
up at S_emulate_setlocale() which does a series of uselocale() calls.
For reference, RHEL 7 is perl 5.16.3 while RHEL 9 is perl 5.32.1. Older
versions of perl do not have this behavior.
The problem with uselocale() is that it changes the active locale away
from the default global locale. Subsequent uses of setlocale() affect
the global locale, but if that is not the active locale, it does not
control the results of locale dependent functions such as localeconv(),
which is what we depend on in PGLC_localeconv().
The result is illustrated in this example:
8<------------
psql test
psql (16beta1)
Type "help" for help.
test=# show lc_monetary;
lc_monetary
-------------
en_GB.UTF-8
(1 row)
test=# SELECT 12.34::money AS price;
price
--------
£12.34
(1 row)
test=# \q
8<------------
psql test
psql (16beta1)
Type "help" for help.
test=# load 'plperl';
LOAD
test=# show lc_monetary;
lc_monetary
-------------
en_GB.UTF-8
(1 row)
test=# SELECT 12.34::money AS price;
price
--------
$12.34
(1 row)
8<------------
Notice that merely loading plperl makes the currency symbol wrong.
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).
I would like to commit this to all supported branches in the next few
days, unless there are other suggestions or objections.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
20230610-plperl_locale_issue-002.patch | text/x-patch | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-06-19 02:29:46 | Re: BUG #17949: Adding an index introduces serialisation anomalies. |
Previous Message | Tom Lane | 2023-06-18 16:16:59 | Re: BUG #17978: Unexpected error: "wrong varnullingrels (b) (expected (b 5)) for Var 6/2" triggered by JOIN |
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2023-06-18 19:57:57 | Re: Do we want a hashset type? |
Previous Message | Tomas Vondra | 2023-06-18 18:22:17 | Re: Use generation context to speed up tuplesorts |