Skip site navigation (1) Skip section navigation (2)

Re: Backup and restore through JDBC

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Marlon Petry <marlonpetry(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backup and restore through JDBC
Date: 2006-09-29 16:49:17
Message-ID: 451D4E8D.2050407@pse-consulting.de (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>   
>> Then after you recover from your head exploding you start devising some 
>> sort of sane API ...
>>     
>
> That's the hard part.  There is no percentage in having a library if
> it doesn't do anything significantly different from what you could
> accomplish via
> 	system("pg_dump ...switches....");
>
> What is it you hope to accomplish by having a library, exactly?
> (And don't say "more control over the dump process". 
Some more progress feedback would be really nice.
>  pg_dump is already
> on the hairy edge of maintainability; we do *not* need to try to deal
> with making it still function correctly after an application programmer
> makes some random intervention in the process.)
>   
Agreed. The only sane approach seems to have a single dump function call
(that takes a set of parameters as prepared by command line scanning)
and a set of callbacks that enable api users to do sensible stuff at
different stages of the backup process.

Regards,
Andreas





In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-29 16:53:19
Subject: Nulls, arrays, records, IS NULL, IS DISTINCT FROM
Previous:From: John D. BurgerDate: 2006-09-29 16:40:48
Subject: Re: [GENERAL] Array assignment behavior (was Re: Stored procedure array limits)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group