Re: zlib for pg_dump - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: zlib for pg_dump
Date
Msg-id Pine.BSF.4.21.0007051442220.33627-100000@thelab.hub.org
Whole thread Raw
In response to Re: zlib for pg_dump  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: zlib for pg_dump  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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 ...




pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Re: zlib for pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection