2010/3/11 Tom Lane <tgl@sss.pgh.pa.us>:
> Now libpq doesn't often have critical security bugs filed against it,
> but it certainly has bugs. Do you really want to have to remember to
> rebuild every piece of dependent software when you update it?
I absolutely agree that linking statically is a terrible idea for
distributions. Debian has a similar prohibition against linking
statically against any other package.
But it does ship static libraries because commercial binary-only
packages often require them. They have to be packaged to work on
multiple OS distributions including some which don't provide
especially smooth dependency systems. You don't want to get calls from
customers running your software against random library versions you've
never tested.
The two (separate) goals which are useful are 1) Provide a library
others can link against to produce a binary which has no run-time
dependency on your library. In this case the only library they might
want to link against would be libpq. The encoding libraries etc aren't
things they're going to link agains. And 2) build binaries which have
no dependencies on system libraries so someone can ship them and
expect them to run on any system regardless of the run-time
environment.
I agree that these are both over-used but they are sometimes the least
bad option. On the other hand, the third goal "avoid using the shared
library facilities" is pointless, I see no reason to avoid building
and loading the encoding code or the contrib modules. They're using
the same technology as shared libraries but they're not really shared
libraries in the sense of being shipped separately from the binaries
using them.
--
greg