Re: localization problem (and solution) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: localization problem (and solution)
Date
Msg-id 7065.1135120395@sss.pgh.pa.us
Whole thread Raw
In response to Re: localization problem (and solution)  (Manuel Sugawara <masm@fciencias.unam.mx>)
Responses Re: localization problem (and solution)  (Andreas Seltenreich <andreas+pg@gate450.dyndns.org>)
List pgsql-hackers
Manuel Sugawara <masm@fciencias.unam.mx> writes:
> While there are reasons to argue that's Perl fault, IMO, an
> environment that reflects the current state of the host program is a
> good compromise, and behave environment-consistent is also a good
> compromise for libperl (I think some applications of libperl will get
> really upset if this compromise is broken by the library.)

I looked into this a bit more, and it seems the issue is that libperl
will dosetlocale(LC_ALL, "");
the first time any locale-related Perl function is invoked.  To defend
ourselves against that, we'd have to set more environment variables than
just LC_COLLATE and LC_CTYPE.

What I'm thinking about is:
* during startup, putenv("LC_ALL=C") and unsetenv any other LC_ variables that may be lurking, except LC_MESSAGES.
* copy LC_COLLATE and LC_CTYPE into the environment when we get them from pg_control, as Manuel suggested.
* in locale_messages_assign(), set the environment variable on all platforms not just Windows.

You could still break the backend by doing setlocale explicitly in
plperlu functions, but that's why it's an untrusted language ...

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: status of concurrent VACUUM patch ...
Next
From: Bruce Momjian
Date:
Subject: I am back online again