Reini Urban <[EMAIL PROTECTED]> writes:With this patch we might want to rename libpq.a to libpq.dll.a in our install step later.
Isn't ".dll.a" a contradiction in terms? This doesn't seem well-thought-out at all to me. Also the end result would have to be much more invasive than you suggest here, since there are many more programs besides pg_ctl that use libpq.
".dll.a": well, that's the fact.
I had terrible problems in compiling apps which link to libpq.a, which actually is libtool problem. it's has very very low urgency.
invasiveness: see the libpq_a patch.
I wonder why you link all clients statically. with a libpq macro you could decide to which version (shared or static) you want to link against.
+ #ifdef __CYGWIN__ + static const int conns[] = {60, 50, 40, 30, 20, 10, 5}; + #else static const int conns[] = {100, 50, 40, 30, 20, 10}; + #endif
This part is just silly. If your system can't support ten connections I think you need to fix your system. Also, we are not in the habit of plastering the source with platform-specific ifdefs just to save a couple of cycles during initialization. If the probe at 100 caused an actual failure on cygwin, I'd accept such a patch, but not otherwise. How legible do you think this code would be if we tried to #ifdef in platform-specific limits for every port we support?
arguments accepted. though the probe for cygwin at 100 causes it NOT to fail. this is actually a more severe problem. It'll stay in my private patches archive. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
