On Mon, Nov 29, 2010 at 10:49 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 29.11.2010 07:11, Joachim Wieland wrote:
>>
>> On Mon, Nov 22, 2010 at 3:44 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> * wrap long lines
>>> * use extern in function prototypes in header files
>>> * "inline" some functions like _StartDataCompressor, _EndDataCompressor,
>>> _DoInflate/_DoDeflate that aren't doing anything but call some other
>>> function.
>>
>> So here is a new round of patches. It turned out that the feature to
>> allow to also restore files from a different dump and with a different
>> compression required some changes in the compressor API. And in the
>> end I didn't like all the #ifdefs either and made a less #ifdef-rich
>> version using function pointers. The downside now is that I have
>> created quite a few one-line functions that Heikki doesn't like all
>> that much, but I assume that they are okay in this case on the grounds
>> that the public compressor interface is calling the private
>> implementation of a certain compressor.
>
> Thanks, I'll take a look.
>
> BTW, I know you wanted to have support for other compression algorithms; I
> think the best way to achieve that is to make it possible to specify an
> external command to be used for compression. pg_dump would fork() and exec()
> that, and pipe the data to be compressed/decompressed to stdin/stdout of the
> external command. We're not going to add support for every new compression
> algorithm that's in vogue, but generic external command support should make
> happy those who want it. I'd be particularly excited about using something
> like pbzip2, to speed up the compression on multi-core systems.
>
> That should be a separate patch, but it's something to keep in mind with
> these refactorings.
That would also ease licensing concerns, since we wouldn't have to
redistribute or bundle anything.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company