Re: localization problem (and solution)

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