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


Tue, 4 Jul 2000 21:57:31 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
zlib for pg_dump
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

Tue, 04 Jul 2000 16:11:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: zlib for pg_dump 
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


Wed, 5 Jul 2000 18:36:33 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: zlib for pg_dump 
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   |/

Thu, 06 Jul 2000 02:49:31 +1000
Philip Warner <pjw@rhyme.com.au>
Re: zlib for pg_dump 
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 ...



Wed, 5 Jul 2000 14:44:27 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: zlib for pg_dump 
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


Thu, 6 Jul 2000 02:15:33 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: zlib for pg_dump 
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


Thu, 6 Jul 2000 18:13:31 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: zlib for pg_dump 
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   |/

Fri, 07 Jul 2000 02:25:27 +1000
Philip Warner <pjw@rhyme.com.au>
Re: zlib for pg_dump 
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


Fri, 7 Jul 2000 18:16:41 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: zlib for pg_dump 