Tom Lane schrieb:
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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

Reply via email to