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
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) |