Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Tom Lane said:
>>> BTW, probably a cleaner answer is to put check_function_bodies into
>>> some header file instead of having an "extern" in the PLs' .c files.
>>> I was thinking about that yesterday, but couldn't decide where was a
>
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> BTW, probably a cleaner answer is to put check_function_bodies into
>> some header file instead of having an "extern" in the PLs' .c files. I
>> was thinking about that yesterday, but couldn't decide where was a good
>> place to put
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I have committed a fix - the perl headers were mangling DLLIMPORT so I
>> moved the declaration above the perl includes.
>
> BTW, probably a cleaner answer is to put check_function_bodies into
> some header file instead of having an "e
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I would also like to add -Wno-comment to the CFLAGS for win32/gcc, top
>> suppress at least some of those warnings.
>
> Why don't you complain to the Perl people, instead? The fact that no
> such warnings occur on Unix Perl installati
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have committed a fix - the perl headers were mangling DLLIMPORT so I
> moved the declaration above the perl includes.
BTW, probably a cleaner answer is to put check_function_bodies into some
header file instead of having an "extern" in the PLs' .c fi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I would also like to add -Wno-comment to the CFLAGS for win32/gcc, top
> suppress at least some of those warnings.
Why don't you complain to the Perl people, instead? The fact that no
such warnings occur on Unix Perl installations makes these seem pre
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We have a build failure to fix first:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-29%2000:44:52
Weird. It seems to be choking on linking to check_function_bodies,
but plpgsql does that exactly the sam
> > The issue is that if I set my machine's locale to Turkish
> or French,
> > say, it doesn't matter what locale I set during initdb or in
> > postgresql.conf, the server's log messages always seem to
> come out in
> > the machine's locale.
>
> Does this happen only for those locales? And ho
> The issue is that if I set my machine's locale to Turkish or
> French, say, it doesn't matter what locale I set during
> initdb or in postgresql.conf, the server's log messages
> always seem to come out in the machine's locale.
Does this happen only for those locales? And how specifically do
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> We have a build failure to fix first:
>>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-29%2000:44:52>
> Weird. It seems to be choking on linking to check_function_bodies, but
> plpgsql does that exactly the same wa
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We have a build failure to fix first:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-29%2000:44:52
Weird. It seems to be choking on linking to check_function_bodies,
but plpgsql does that exactly the same way, and there's no prob
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
Andrew Dunstan <[EMAIL PROTECTED]> 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?
We
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 ---
"Andrew Dunstan" <[EMAIL PROTECTED]> 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
Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> 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
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 cod
Tom Lane said:
> Andreas Seltenreich <[EMAIL PROTECTED]> 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 th
Andreas Seltenreich <[EMAIL PROTECTED]> 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 ne
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 an
Manuel Sugawara 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
>
Tom Lane <[EMAIL PROTECTED]> 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 l
Manuel Sugawara writes:
> Some fprintf's around the regex code shows that someone is changing
> the localization parameters by those found in the enviroment, at least
> for the LC_CTYPE and LC_COLLATE categories, and plperl seems to be the
> culprit.
Indeed. Please file a bug with the Perl peopl
Here is a test case for a previously reported bug (see
http://archives.postgresql.org/pgsql-general/2005-11/msg01235.php):
initdb using es_MX.ISO-8859-1, start postgres using es_MX.UTF-8 and
execute:
create procedural language plperl;
create or replace function foo() returns int as 'return 1' lan
24 matches
Mail list logo
