Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
Date
Msg-id 1136991512.3097.4.camel@swithin
Whole thread Raw
In response to plperl vs LC_COLLATE (was Re: Possible savepoint bug)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
The original of this email appears to have disappeared into the ether. 

cheers

andrew

-------- Forwarded Message --------
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <gsstark@mit.edu>, Michael Paesold <mpaesold@gmx.at>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint
bug)
Date: Tue, 10 Jan 2006 10:22:45 -0500

On Mon, 2006-01-09 at 11:03 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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.
> 


It just occurred to me that one way to do this so that perl's
book-keeping was intact would be to have perl do the work. We could
insert some calls to POSIX::setlocale() into the interpreter startup
code, instead of restoring the locale by direct C calls.

Not sure if it's worth doing, though.

cheers

andrew



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: leaks in TopMemoryContext?
Next
From: Tom Lane
Date:
Subject: Re: PG process architecture