On 2012-12-05 19:40:58 +0200, Heikki Linnakangas wrote: > 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).
For me it seems pretty natural to support dumping extension the way they got created. I.e. a plain CREATE EXTENSION ...; if the extension was preinstalled and some form that includes the extension source if you installed it via the connection. Extensions that were installed in some global manner *should* not be dumped with ones installed over the connection. E.g. dumping /contrib or packaged modules seems to be a bad idea to me. That would possibly be useful as a debugging tool, but I don't see much point besides that. > 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. What would be the case for the per-cluster in the case of uploaded extensions? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
