Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: localization problem (and solution)


  • From: Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: localization problem (and solution)
  • Date: Wed, 21 Dec 2005 08:06:44 +0100
  • Message-id: <87wthzhqt7(dot)fsf(at)gate450(dot)dyndns(dot)org>

Tom Lane writes:

> I looked into this a bit more, and it seems the issue is that libperl
> will do
> 	setlocale(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.

I'm afraid having LC_ALL in the environment at this time would still
do the wrong thing on setlocale(LC_ALL, ""); since a LC_ALL
environment variable overrides the other categories. Maybe setting
LANG instead would be a better choice?

regards,
Andreas
-- 



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group