Re: Is a plan for lmza commpression in pg_dump - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Is a plan for lmza commpression in pg_dump
Date
Msg-id E393A0D3-12A1-4838-8474-5DE15C276017@gmail.com
Whole thread Raw
In response to Re: Is a plan for lmza commpression in pg_dump  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Is a plan for lmza commpression in pg_dump  (Bruce Momjian <bruce@momjian.us>)
Re: Is a plan for lmza commpression in pg_dump  (David Fetter <david@fetter.org>)
Re: Is a plan for lmza commpression in pg_dump  (daveg <daveg@sonic.net>)
Re: Is a plan for lmza commpression in pg_dump  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
On Feb 7, 2009, at 4:53 PM, Bruce Momjian <bruce@momjian.us> wrote:

> Robert Haas wrote:
>>> That this comes up "much to often" suggests that there is more  
>>> than near
>>> zero interest.  Why can only one compression library can be  
>>> considered?
>>> We use multiple readline implementations, for better or worse.
>>>
>>> I think the context here is for pg_dump only and in that context a  
>>> faster
>>> compression library makes a lot of sense. I'd be happy to prepare  
>>> a patch
>>> if the license issue can be accomodated. Hence my question, what  
>>> sort of
>>> licence accomodation would we need to be able to use this library?
>>
>> Based on previous discussions, I suspect that the answer here is
>> "complete relicensing as BSD".  I think pursuing any sort of  
>> licensing
>> exception is completely futile as there will still be restrictions
>> that will be unacceptable to many in the community.
>>
>> But if someone had an actual BSD-LICENSED compression library that  
>> was
>> better than what we have now, I'm not sure why Bruce (or anyone)
>> should be opposed to incorporating it.  It's just that all of the
>> proposals that come up for this sort of thing aren't that.
>
> You can be I would oppose it.  It is not efficient for us to support
> every compression-of-the-month project that comes along.  If something
> was BSD, well tested, and clearly superior, we might consider it,  
> but I

Well that's pretty much what I said.

> have seen nothing like that for 10 years and I doubt I will see
> something the next 5.  I am thinking

I am doubtful too.

> we need to add this to the
> "Features we do not want" section of our todo list.

"Proprietary compression algorithms, even with Postgresql-specific  
license exceptions"?

...Robert 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Is a plan for lmza commpression in pg_dump
Next
From: Bruce Momjian
Date:
Subject: Re: Is a plan for lmza commpression in pg_dump