SEO

Tom Lane <tgl@sss.pgh.pa.us> writes:

> (Your proposed fix seems entirely useless ...

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.)

Regards,
Manuel.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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 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.
* 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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
--

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Andreas Seltenreich <andreas+pg@gate450.dyndns.org> writes:
> 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.

Doh, of course, I was misremembering the precedence. So we need
LANG=C
LC_ALL unset (probably LANGUAGE too, for glibc)
others as stated

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane said:
> Andreas Seltenreich <andreas+pg@gate450.dyndns.org> writes:
>> 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.
>
> Doh, of course, I was misremembering the precedence. So we need
> LANG=C
> LC_ALL unset (probably LANGUAGE too, for glibc)
> others as stated
>


We need to test any solution carefully on Windows, which deals with locales
very differently from *nix, and where we still have some known locale issues
(see recent discussion).

I wonder if the complained of behaviour is triggered by our recent changes
to support utf8 in pl/perl?

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Andrew Dunstan" <andrew@dunslane.net> writes:
> We need to test any solution carefully on Windows, which deals with locales
> very differently from *nix, and where we still have some known locale issues

Right, of course. I was thinking that this change might actually bring
the Windows and Unix code closer together --- at least for LC_MESSAGES
it seems it would do so.

If I prepare a patch, do you want to test it on Windows before it goes
in, or is it easier just to commit and then test CVS tip?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane said:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
>> We need to test any solution carefully on Windows, which deals with
>> locales very differently from *nix, and where we still have some known
>> locale issues
>
> Right, of course. I was thinking that this change might actually bring
> the Windows and Unix code closer together --- at least for LC_MESSAGES
> it seems it would do so.
>
> If I prepare a patch, do you want to test it on Windows before it goes
> in, or is it easier just to commit and then test CVS tip?
>


Can't do anything for cvs tip until the md5 mess is fixed.

I don't have much time to spare for testing till at least next week - maybe
someone else does.

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Andrew Dunstan" <andrew@dunslane.net> writes:
> We need to test any solution carefully on Windows, which deals with locales
> very differently from *nix, and where we still have some known locale issues
> (see recent discussion).

I've committed a proposed change in HEAD --- would you check out the
Windows behavior at your convenience? If it seems to work, I'll
back-patch, but let's test first.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:

>"Andrew Dunstan" <andrew@dunslane.net> writes:
>
>
>>We need to test any solution carefully on Windows, which deals with locales
>>very differently from *nix, and where we still have some known locale issues
>>(see recent discussion).
>>
>>
>
>I've committed a proposed change in HEAD --- would you check out the
>Windows behavior at your convenience? If it seems to work, I'll
>back-patch, but let's test first.
>
>
>
>

Will try. Not quite sure how, though. Any suggestions?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I've committed a proposed change in HEAD --- would you check out the
>> Windows behavior at your convenience? If it seems to work, I'll
>> back-patch, but let's test first.

> Will try. Not quite sure how, though. Any suggestions?

Well, one thing to try is whether you can reproduce the plperl-induced
breakage I posted this morning on Windows; and if so whether the patch
fixes it.

Also, what were those "known locale issues" you were referring to?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster