Tom Lane wrote:
> "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....
>> 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
In response to
pgsql-hackers by date
|Next:||From: Hiroshi Saito||Date: 2009-12-30 15:57:09|
|Subject: Re: test/example does not support win32.|
|Previous:||From: Tom Lane||Date: 2009-12-30 15:44:49|
|Subject: Re: test/example does not support win32. |