Re: test/example does not support win32.

Hi Andrew-san.

Although this is a standard in windows.

*** testlibpq2.c.orig   Wed Dec 30 13:19:03 2009
--- testlibpq2.c        Thu Dec 31 00:52:52 2009
***************
*** 24,34 ****
--- 24,39 ----  *  *     INSERT INTO TBL1 VALUES (10);  */
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <sys/time.h>
+ #include <sys/types.h> #include "libpq-fe.h"
 static void

Does this become the standard which you consider?
or #IFDEF Isn't it allowed?

Regards,
Hiroshi Saito

----- Original Message ----- 
From: "Andrew Dunstan" <andrew@dunslane.net>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>; "Alvaro Herrera" 
<alvherre@commandprompt.com>; "pgsql-hackers" <pgsql-hackers@postgresql.org>; "Bruce 
Momjian" <bruce@momjian.us>
Sent: Thursday, December 31, 2009 12:45 AM
Subject: Re: [HACKERS] test/example does not support win32.


>
>
> Tom Lane wrote:
>> "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
>>
>>> Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set 
>>> complains.... Thanks!
>>>
>>
>>
>>> It seems that pg_bench takes the thing same again into consideration. Anyway,  If it is 
>>> called example of end-user code, what is the evasion method
>>> of fd_set?
>>
>> On reflection I think it's just wrong to expect that the examples will
>> compile out-of-the-box on every platform.  The only way that that can
>> possibly happen is if they depend on our configuration infrastructure,
>> which is exactly what I feel they should not depend on.  Any client
>> program that has ambitions of portability is going to have its own
>> autoconf stuff, so injecting ours into a piece of sample code is just
>> going to result in headaches.  Even including only pg_config.h would
>> be a serious invasion of application namespace.
>>
>> Looking at pgbench, or any other one of our client-side programs,
>> is not relevant to the point here.  Those programs *are* supposed
>> to rely on the PG autoconf environment.
>>
>> We can certainly add some more standard #includes to the examples
>> if they're obviously missing some.  But that isn't going to get us
>> to a point where they'll compile everywhere without change.
>>
>>
>>
>
> That would be all good and well if we didn't already rely on the configure setup. But we 
> do - the Makefile includes src/Makefile.global, which is built by configure.
>
> Anyway, let's see how far we can get with including some standard header files.
>
> cheers
>
> andrew