Tom Lane wrote:

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

We have a build failure to fix first:
http://www.pgbuildfarm.org/cgi-bin/s...-29%2000:44:52

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


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.

cheers

andrew

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

Andrew Dunstan <andrew@dunslane.net> writes:
> We have a build failure to fix first:
> http://www.pgbuildfarm.org/cgi-bin/s...-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 problem
there. I wonder whether all those warnings in the perl header files
mean anything ...

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

Is this possibly related to the fact that we don't even try to do
setlocale() for LC_MESSAGES?

regards, tom lane

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

Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> 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 problem there.
> I wonder whether all those warnings in the perl header files mean
> anything ...

We always get those - see
http://www.pgbuildfarm.org/cgi-bin/s...12&stg=makefor example. One day when I get time I want to clean them up.

>
>> 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.
>
> Is this possibly related to the fact that we don't even try to do
> setlocale() for LC_MESSAGES


We can't on Windows - it doesn't define LC_MESSAGES. But libintl does some
stuff, I believe.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>We have a build failure to fix first:
>>http://www.pgbuildfarm.org/cgi-bin/s...-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 problem
>there. I wonder whether all those warnings in the perl header files
>mean anything ...
>
>
>

I have committed a fix - the perl headers were mangling DLLIMPORT so I
moved the declaration above the perl includes.

I would also like to add -Wno-comment to the CFLAGS for win32/gcc, top
suppress at least some of those warnings.

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:
> 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 pretty
suspicious.

regards, tom lane

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

Andrew Dunstan <andrew@dunslane.net> 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 files. I was
thinking about that yesterday, but couldn't decide where was a good
place to put it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> 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 pretty
> suspicious.
>


Well, it's probably not even the Perl people - perl's config_h.SH seems to
do the right thing and put a space between the second / and *, so that the
compiler won't complain, so it could be ActiveState's doing. Maybe I'll just
make a tiny script to fix config.h in my perl distro.


There is a more serious problem, though, in these warnings. Perl is
apparently trying to hijack the *printf functions, just as libintl tries to
do. There's a #define we can set to inhibit that, and I think we should.
That would leave 2 lots of warnings to fix - one about uid_t/gid_t and one
about isnan.

cheers

andrew




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> 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 files. I
> was thinking about that yesterday, but couldn't decide where was a good
> place to put it.
>


miscadmin.h ?

cheers

andrew




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

http://archives.postgresql.org

"Andrew Dunstan" <andrew@dunslane.net> 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 it.

> miscadmin.h ?

Ugh :-( I was thinking about pg_proc.h, because the variable itself is
in pg_proc.c, but that seems pretty ugly too. Another possibility is to
move the variable someplace else...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane said:
> "Andrew Dunstan" <andrew@dunslane.net> 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 it.
>
>> miscadmin.h ?
>
> Ugh :-( I was thinking about pg_proc.h, because the variable itself is
> in pg_proc.c, but that seems pretty ugly too. Another possibility is
> to move the variable someplace else...


I trust whatever choice you make.

cheers

andrew



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