From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us> |
Subject: | Re: test/example does not support win32. |
Date: | 2009-12-30 15:33:59 |
Message-ID: | 17336.1262187239@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-12-30 15:38:12 | Re: test/example does not support win32. |
Previous Message | Hiroshi Inoue | 2009-12-30 15:27:45 | krb_server_keyfile setting doesn't work on Windows |