Re: Dumping an Extension's Script

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