Tom Lane schrieb:
> Reini Urban <rurban@x-ray.at> 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/
