Re: pluggable compression support

On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-06-14 17:35:02 -0700, Josh Berkus wrote:
>>
>> > No. I think as long as we only have pglz and one new algorithm (even if
>> > that is lz4 instead of the current snappy) we should just always use the
>> > new algorithm. Unless I missed it nobody seemed to have voiced a
>> > contrary position?
>> > For testing/evaluation the guc seems to be sufficient.
>>
>> Then it's not "pluggable", is it?  It's "upgradable compression
>> support", if anything.  Which is fine, but let's not confuse people.
>
> The point is that it's pluggable on the storage level in the sense of
> that several different algorithms can coexist and new ones can
> relatively easily added.
> That part is what seems to have blocked progress for quite a while
> now. So fixing that seems to be the interesting thing.
>
> I am happy enough to do the work of making it configurable if we want it
> to be... But I have zap interest of doing it and throw it away in the
> end because we decide we don't need it.

I don't think we need it.  I think what we need is to decide is which
algorithm is legally OK to use.  And then put it in.

In the past, we've had a great deal of speculation about that legal
question from people who are not lawyers.  Maybe it would be valuable
to get some opinions from people who ARE lawyers.  Tom and Heikki both
work for real big companies which, I'm guessing, have substantial
legal departments; perhaps they could pursue getting the algorithms of
possible interest vetted.  Or, I could try to find out whether it's
possible do something similar through EnterpriseDB.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company