Re: Dumping an Extension's Script
От | Heikki Linnakangas |
---|---|
Тема | Re: Dumping an Extension's Script |
Дата | |
Msg-id | 50BF872A.7050309@vmware.com обсуждение исходный текст |
Ответ на | Re: Dumping an Extension's Script (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Dumping an Extension's Script
Re: Dumping an Extension's Script Re: Dumping an Extension's Script |
Список | pgsql-hackers |
On 05.12.2012 19:27, Andres Freund wrote: >> And I still don't understand why pg_dump needs to know about any of this... > > Extensions should be fully per-database and we want pg_dump backups to > be restorable into another database/clusters/servers. So having a mode > for pg_dump that actually makes dumps that are usable for recovering > after a disaster seems sensible to me. Otherwise you need to redeploy > from the VCS or whatever, which isn't really what you want when > restoring a database backup. Ok - but that it yet another issue, not to be confused with how you deploy extensions. If we are to have such a mode in pg_dump, it should be able to dump *all* extensions, regardless of how they were deployed. (ok, might be difficult for extensions that include .so files or similar, but certainly for an extension that only contains a .sql file and a .control file, it shouldn't matter how it was deployed). And whether extension control files (or the same information stored in a table or wherever) should be per-database or per cluster - that's *yet* another separate issue. You could argue for either behavior. - Heikki
В списке pgsql-hackers по дате отправления: