Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)

On Mon, 2006-01-09 at 11:03 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > AFAICT, perl doesn't keep any state about locale settings, it just
> > reacts to whatever the current settings are, I think, but I could be wrong.
>
> If that's the case, why would it be bothering to issue setlocale during
> startup at all? If you look in locale.c in the Perl sources, it's
> pretty clear that it saves away state about the settings during
> Perl_init_i18nl10n(). I'm too lazy to track down where that state is
> used or what the consequences are if it's wrong, but it sure looks to
> me like *something* will be broken if we just change the locale back
> to what we want afterward.
>

I don't know. Reading that code just makes my head spin ...

I should have thought a library shouldn't make too many assumptions
about locale settings anyway. What is to prevent another library from
doing the same thing. Then we'd have duelling settings, dependent on who
got called last.

I had thought, from reading perl's locale.c, that unsetting LC_COLLATE
and LANG would inhibit the calls to setlocale(LC_ALL,"") and
setlocale(LC_COLLLATE,""). But my testing seemed to prove that wrong. Of
course, it's possible that ActiveState's perl is not doing quite the
same thing. At any rate, what I think we know from that code is that on
Windows, just setting LANG and LC_* is precisely the wrong thing, since
the presence of those values will trigger a call to setlocale(LC_foo,"")
but the relevant environment value will not actually be used.

I'm just about out of ideas and right out of time to spend on this.

cheers

andrew