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" <and...@dunslane.net>
To: "Tom Lane" <t...@sss.pgh.pa.us>
Cc: "Hiroshi Saito" <z-sa...@guitar.ocn.ne.jp>; "Alvaro Herrera"
<alvhe...@commandprompt.com>; "pgsql-hackers" <pgsql-hackers@postgresql.org>; "Bruce
Momjian" <br...@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-sa...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
