Message-ID: <4CEAD61A.6060207@enterprisedb.com>
Date: Mon, 22 Nov 2010 22:44:10 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10
MIME-Version: 1.0
To: Joachim Wieland <joe@mcknight.de>
CC: Tom Lane <tgl@sss.pgh.pa.us>, =?ISO-8859-1?Q?Jos=E9_Arthur_Beneta?=
	=?ISO-8859-1?Q?sso_Villanova?= <jose.arthur@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: directory archive format for pg_dump
References: <AANLkTi=AEi3F6jC0Zy3dG9njiwJJC8Y6V090-hMonyyn@mail.gmail.com>
	<AANLkTik+PR2HCsqS7PVAdETPyKSGn2hb-eTeg9QZpRew@mail.gmail.com>
	<4CEA9F29.5060106@enterprisedb.com>
	<28890.1290445623@sss.pgh.pa.us>
In-Reply-To: <28890.1290445623@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 22.11.2010 19:07, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> But I'm not actually sure we should be preventing mix&  match of files
>> from different dumps. It might be very useful to do just that sometimes,
>> like restoring a recent backup, with the contents of one table replaced
>> with older data. A warning would be ok, though.
>
> +1.  This mechanism seems like a solution in search of a problem.
> Just lose the whole thing, and instead fix pg_dump to complain if
> the target directory isn't empty.  That should be sufficient to guard
> against accidental mixing of different dumps, and as Heikki says
> there's not a good reason to prevent intentional mixing.

Extending that thought a bit, it would be nice if the per-file header 
would carry the info if the file is compressed or not, instead of just 
one such flag in the TOC. You could then also mix & match files from 
compressed and non-compressed archives.

Other than the md5 thing, the patch looks fine to me. There's many quite 
levels of indirection, it took me a while to get my head around the call 
chains like DataDumper->_WriteData->WriteDataToArchive->_WriteBuf, but I 
don't have any ideas on how to improve that.

However, docs are missing, so I'm marking this as "Waiting on Author".

There's some cosmetic changes I'd like to have fixed or do myself before 
committing:

* 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.

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