Thread: zlib for pg_dump
I think we need a --with-zlib switch for the new pg_dump. Or at least a --without-zlib switch, if you think that it's widespread enough. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> I think we need a --with-zlib switch for the new pg_dump. Or at least a
> --without-zlib switch, if you think that it's widespread enough.
Seems reasonable to me to look for libz automatically in the library
search path. A --with switch would only serve as an addition to the
LIBS directory list, and as I commented in another connection I see no
good reason for adding a bunch of variant spellings of --with-libs ...
regards, tom lane
At 21:57 4/07/00 +0200, Peter Eisentraut wrote: >I think we need a --with-zlib switch for the new pg_dump. Or at least a >--without-zlib switch, if you think that it's widespread enough. As far as I am aware, te plan is to make 'configure' check for it...the code obeys the HAVE_ZLIB #define when compiling. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Tom Lane writes: > > I think we need a --with-zlib switch for the new pg_dump. Or at least a > > --without-zlib switch, if you think that it's widespread enough. > > Seems reasonable to me to look for libz automatically in the library > search path. A --with switch would only serve as an addition to the > LIBS directory list, and as I commented in another connection I see no > good reason for adding a bunch of variant spellings of --with-libs ... As I might have commented before, I'm not so excited about adding and dropping features without explicit user interaction. zlib is probably widespread enough to assume it by default, but then the build must fail if the library is not installed, and the user must indicate his consent by using the --without-zlib flag. We have to be able to determine the set of features that will be build by examining the configure command line, not by scanning the configure output, or worse yet, by finding out that the program doesn't behave as expected. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 18:36 5/07/00 +0200, Peter Eisentraut wrote: >Tom Lane writes: >> >> Seems reasonable to me to look for libz automatically in the library >> search path. A --with switch would only serve as an addition to the >> LIBS directory list, and as I commented in another connection I see no >> good reason for adding a bunch of variant spellings of --with-libs ... ... >We have to be able to determine the set of >features that will be build by examining the configure command line The feature (compressed backup output in pg_dump) is not readily deducible from '--with-zlib'. It might be better to output a message from configure if a needed library is not found: "zlib compression library not found, pg_dump archives will not support compression". if, in the future, there is a gzip datatype, we could also output 'gzip data types will not be supported' etc. Alternatively, have a very specific flag: --with-compressed-dumps, then die if there is no zlib. But I'd stick with the check for zlib, since it is pretty common. The *only* feature you lose by not having it is the compressed output in dumps: if you request compression, it issues a warning and produces uncompressed output. The archives are still readable when zlib is installed (and vice verca in the case of -Z0). ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Wed, 5 Jul 2000, Philip Warner wrote: > At 21:57 4/07/00 +0200, Peter Eisentraut wrote: > >I think we need a --with-zlib switch for the new pg_dump. Or at least a > >--without-zlib switch, if you think that it's widespread enough. > > As far as I am aware, te plan is to make 'configure' check for it...the > code obeys the HAVE_ZLIB #define when compiling. the other way ... autoconf defines it as 'HAVE_LIBZ' ... and configure now tests for it ...
On Wed, 5 Jul 2000, Peter Eisentraut wrote: > Tom Lane writes: > > > > I think we need a --with-zlib switch for the new pg_dump. Or at least a > > > --without-zlib switch, if you think that it's widespread enough. > > > > Seems reasonable to me to look for libz automatically in the library > > search path. A --with switch would only serve as an addition to the > > LIBS directory list, and as I commented in another connection I see no > > good reason for adding a bunch of variant spellings of --with-libs ... > > As I might have commented before, I'm not so excited about adding and > dropping features without explicit user interaction. zlib is probably > widespread enough to assume it by default, but then the build must > fail if the library is not installed, and the user must indicate his > consent by using the --without-zlib flag. We have to be able to > determine the set of features that will be build by examining the > configure command line, not by scanning the configure output, or worse > yet, by finding out that the program doesn't behave as expected. I don't agree ... unless we're gonna add this for libreadline (optional) and anything else that is "optional". IMHO, if the system has the functionality that extends the usefulness of the software, don't make the installer go off looking for how to make use of it ...
Philip Warner writes: > The feature (compressed backup output in pg_dump) is not readily deducible > from '--with-zlib'. It might be better to output a message from configure > if a needed library is not found: > > "zlib compression library not found, pg_dump archives will not support > compression". That's exactly what we should not do. You forget that not only humans run configure scripts, it might be other programs, which can't "read". -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 14:42 5/07/00 -0300, The Hermit Hacker wrote: > >the other way ... autoconf defines it as 'HAVE_LIBZ' ... and configure now >tests for it ... > Fixed in my copy; I'll send a patch as soon as I hear from Jan regarding the problems he reported. Let me know if you want a patch sooner. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
The Hermit Hacker writes: > I don't agree ... unless we're gonna add this for libreadline > (optional) and anything else that is "optional". We already do this for everything else that's optional, except for readline, which I consider wrong, but there's probably no support to be gained for that. The fact that it is virtually impossible to determine whether readline and/or history support is supported in psql until you have installed and used it is a major source of user problems. > IMHO, if the system has the functionality that extends the usefulness > of the software, don't make the installer go off looking for how to > make use of it ... That's why I suggested assuming it by default and turn if *off* manually. The reason why I'm so keen about this is this: configure scripts are not only run by humans, but also by programs, and the only thing programs can rely on is a non-zero exit status. config.status is one such program. Others are source RPMs and other packaging mechanisms. Rebuilding a source RPM is an enlightening experience: You get all kinds of garbage flying by on your screen, and the end you only hope that something reasonable came out. But if not even the build script can determine what it's going to build, then you really lose. The failure modes are plenty. You don't even have to be on a different machine or fiddle with your installed packages. Maybe the sysadmin simply reran /sbin/ldconfig after forgetting for a few months. Before you know it you have shipped the package off to thousands of people who wonder why feature X won't work. The bottom line is, the packager/builder needs a way to specify what exactly is going to be built. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 18:13 6/07/00 +0200, Peter Eisentraut wrote: > >The bottom line is, the packager/builder needs a way to specify what >exactly is going to be built. > What about a compromise: --enable-zlib, --disable-zlib. configure should check for zlib if neither of these is specified, otherwise if just uses these. You also need to be careful: if --enable-zlib is specified and configure could not find zlib.h, something needs to be done... ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner writes: > What about a compromise: --enable-zlib, --disable-zlib. > > configure should check for zlib if neither of these is specified, otherwise > if just uses these. I like that. > You also need to be careful: if --enable-zlib is specified and configure > could not find zlib.h, something needs to be done... True, especially on RPM systems that don't install the header files by default. Actually, there is a CHECK_ZLIB macro in the official Autoconf macro archive that does this sort of thing, but it rather follows my original suggestions of yes/no, rather than your idea of yes/no/maybe. But maybe we can reutilize that anyway in some form. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden