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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paesold <mpaesold(at)gmx(dot)at>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
Date: 2006-01-09 12:17:12
Message-ID: 43C25448.3080301@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark wrote:

>>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>
>>>The attached patch against cvs tip does seem to work. Instead of playing
>>>with the environment, we simply allow perl to do its worst and then put
>>>things back the way we wanted them.
>>>
>>>
>
>How does that affect to the API calls you can make from Perl back into the
>database? What if you change the locale and then issue a query from within
>Perl?
>
>
>

If you deliberately change the locale settings (especially LC_COLLATE),
all bets are off, surely. REINDEX will be in your future.

Calling setlocale() is in fact a forbidden operation in trusted plperl.

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.

My main concern has been that we are pushing out a point release that
advertises a fix for a problem, when the fix doesn't work on Windows.
Either we need to find a fix (and I tried to supply one) or we need to
change what we say about the release.

I'm also a bit distressed that nobody else has tested this, and we have
just assumed that the fix would work, despite what we already know about
how setlocale() works on Windows.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2006-01-09 13:35:11 Re: ISO 8601 Intervals
Previous Message Michael Glaesemann 2006-01-09 11:45:40 Re: ISO 8601 Intervals