Re: -f
От | Andrew Dunstan |
---|---|
Тема | Re: -f |
Дата | |
Msg-id | 45AB9A0C.6000204@dunslane.net обсуждение исходный текст |
Ответ на | Re: -f (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: -f
|
Список | pgsql-hackers |
Neil Conway wrote: > On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: > >> I don't think they need to be integrated any time soon, but if we were >> to design pg_dump and pg_dumpall from scratch, it seems more logical to >> use a single program >> > > On thinking about this some more, it might be useful to factor much of > pg_dump's logic for reconstructing the state of a database into a shared > library. This would make it relatively easy for developers to plug new > archive formats into the library (in addition to the present 3 archive > formats), or to make use of this functionality in other applications > that want to reconstruct the logical state of a database from the > content of the system catalogs. We could then provide a client app > implemented on top of the library that would provide similar > functionality to pg_dump. > > Moving pg_dump's functionality into the backend has been suggested in > the past (and rejected for good reason), but I think this might be a > more practical method for making the pg_dump logic more easily reusable. > > > I like this idea. For example, we might usefully map some of this to psql \ commands, without having to replicate the underlying logic. cheers andrew
В списке pgsql-hackers по дате отправления: