Re: QSoC proposal: Rewrite pg_dump and pg_restore
От | Tom Lane |
---|---|
Тема | Re: QSoC proposal: Rewrite pg_dump and pg_restore |
Дата | |
Msg-id | 32032.1395371380@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: QSoC proposal: Rewrite pg_dump and pg_restore (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: QSoC proposal: Rewrite pg_dump and pg_restore
Re: QSoC proposal: Rewrite pg_dump and pg_restore Re: QSoC proposal: Rewrite pg_dump and pg_restore |
Список | pgsql-hackers |
Craig Ringer <craig@2ndquadrant.com> writes: > Here's how I think it needs to look: > [ move all the functionality to the backend ] Of course, after you've done all that work, you've got something that is of exactly zero use to its supposed principal use-case, pg_dump. pg_dump will still have to support server versions that predate all these fancy new dump functions, and that pretty much ensures that most of pg_dump's core functionality will still be on the client side. Or, if you try to finesse that problem by making sure the new server APIs correspond to easily-identified pieces of pg_dump code, you'll probably end up with APIs that nobody else wants to use :-(. In any case, I quite agree with the sentiment that this is not a suitable problem for a GSOC project. regards, tom lane
В списке pgsql-hackers по дате отправления: