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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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