>> This remoinded me of a question I wanted to ask Unix people: other OSs I
>> use allow for dynamic linking, at runtime and in code, against shared
>> libraries, and I know Unix must allow this. The places where zlib is used
>> are pretty limited, so it might be worth considering doing the 'HAVE_ZLIB'
>> kinds of checks at runtime. Then one binary fits all...
> We do dynamic loading for functions. Not sure if we want to load zlib
> dynamically if we can help it.
Not bloody likely! Do you want to be in a position where you restart
your postmaster and suddenly chunks of your database are inaccessible?
That's what could happen to you if someone moves or deletes libz.so.
I don't mind being dynamically linked to standard system shared libs;
if libc.so is busted then whether Postgres launches is the least of
your worries. But dynamic dependence on an optional package that's
probably living in /usr/local strikes me as exceedingly risky.
If we do go with using zlib instead of homegrown code, I would recommend
building and statically linking to our own copy even if there is a copy
available on the system. This will prevent cross-version compatibility
problems as well as where'd-my-library-go syndrome. We cannot afford
those sorts of risks for something that could prevent us from reading
our database.
regards, tom lane
