Re: directory archive format for pg_dump
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Joachim Wieland <joe@mcknight.de>, Tom Lane <tgl@sss.pgh.pa.us>, José Arthur Benetasso Villanova <jose.arthur@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-11-29T16:06:04Z
Lists: pgsql-hackers
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