On 2013-06-15 13:11:47 +0200, Hannu Krosing wrote: > If it were truly pluggable - that is just load a .dll, set a GUG and start > using it
Ok. I officially rechristen the patchset to 'extensible compression support'. > - then the selection of algorithms would be much > wider as several slow-but-high-compression ones under GPL could be > used as well, similar to how currently PostGIS works. > gzip and bzip2 are the first two that came in mind, but I am sure there > are more. gzip barely has a higher compression ratio than lz4 and is a magnitude slower decompressing, so I don't think it's interesting. I personally think bzip2 is too slow to be useful, even for decompression. What might be useful is something like lzma, but it's implementation is so complex that I don't really want to touch it. > > 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. > Making a truly pluggable compression API delegates this question > to end users. > > Delegation is good, as it lets you get done more :) No. It increases the features complexity by a magnitude. That's not good. And it means that about nobody but a few expert users will benefit from it, so I am pretty strongly opposed. You suddently need to solve the question of how the identifiers for compression formats are allocated and preserved across pg_upgrade and across machines. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
