Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...

>> 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