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.
Well, those example programs are pretty clean libpq apps so I don't see why they should using platform-specific stuff. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
