Re: directory archive format for pg_dump

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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com