Message-ID: <4CEA9F29.5060106@enterprisedb.com>
Date: Mon, 22 Nov 2010 18:49:45 +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: =?ISO-8859-1?Q?Jos=E9_Arthur_Benetasso_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>
In-Reply-To: <AANLkTik+PR2HCsqS7PVAdETPyKSGn2hb-eTeg9QZpRew@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 20.11.2010 06:10, Joachim Wieland wrote:
> 2010/11/19 José Arthur Benetasso Villanova<jose.arthur@gmail.com>:
>> The md5.c and kwlookup.c reuse using a link doesn't look nice either.
>> This way you need to compile twice, among others things, but I think
>> that its temporary, right?
>
> No, it isn't. md5.c is used in the same way by e.g. libpq and there
> are other examples for links in core, check out src/bin/psql for
> example.

It seems like overkill to include md5 just for hashing the random bytes 
that getRandomData() generates. And if random() doesn't produce unique 
values, it's not going to get better by hashing it. How about using a 
timestamp instead of the hash?

If you don't initialize random() with srandom(), BTW, it will always 
return the same value.

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.

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