Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... - Mailing list pgsql-hackers

From Philip Warner
Subject Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Date
Msg-id 3.0.5.32.20000708125646.02bf9aa0@mail.rhyme.com.au
Whole thread Raw
In response to Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 22:28 7/07/00 -0400, Tom Lane wrote:
>
>pg_dump is rather a different case.  I would want to see a runtime
>option *not* to use compression

That's there already; using -Z0 produces the same output as a mchine
without zlib.

>But making an uncompressed dump today doesn't invalidate
>the compressed dump you made yesterday, nor vice versa.

Not sure what you mean here.


>Good point.  If we include zlib in the distribution it would be pretty
>silly for pg_dump not to use it.  If we don't, then Peter's remarks
>about not liking an environment-determined feature set are relevant.

zlib seems to have been ported to zillions of architectures (must be a good
design ;-}), so it's probably pretty safe to put in the source tree, and
I'm sure any porting problems we encounter would be useful to the zlib
maintainers.

If we don't want to use zlib, then fefore using Jan's compression code in
pg_dump, I suppose I'd need to know that the output is compatible across
32/64 bit architectures and is not sensitive to other issues like endian-ness.


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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq / SQL3
Next
From: Chris Bitmead
Date:
Subject: Re: libpq / SQL3