Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> 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).
That's what you have in the current patch. Try
=> create extension 'hstore'; $ pg_dump --extension-script hstore
It works as far as the script is concerned, and the control file is not
needed any more because the script as dumped does not need it, except
for the two parameters 'require' and 'relocatable', that are added in
the SQL command.
The binary file is not taken care of by this mechanism. Remember that in
most cases pg_restore will not be granted to deploy it at the right
place anyway, for security reasons.
> 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.
At the SQL level, extensions do live in a database. The only reason why
we currently have them on the file system is binary executables (.so,
.dylib, .dll). And those are not per database, not even per cluster, not
even per major version, they are *per server*. It's something that makes
me very sad, and that I want to have the chance to fix later, but that
won't happen in 9.3, and certainly not in that very patch…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support