Re: directory archive format for pg_dump

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: José Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: directory archive format for pg_dump
Date: 2010-11-22 16:49:45
Message-ID: 4CEA9F29.5060106@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20.11.2010 06:10, Joachim Wieland wrote:
> 2010/11/19 José Arthur Benetasso Villanova<jose(dot)arthur(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-22 16:51:27 Re: dblink versus long connection strings
Previous Message Itagaki Takahiro 2010-11-22 16:44:52 Re: dblink versus long connection strings