Re: directory archive format for pg_dump
От | Robert Haas |
---|---|
Тема | Re: directory archive format for pg_dump |
Дата | |
Msg-id | AANLkTikiJd1d1+1SJTNmDUwp6HJ2nTKinef8U6nuHEcj@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: directory archive format for pg_dump (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: