On Mon, Jan 23, 2012 at 10:04 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> And then basebackup and pg_upgrade would just work, and for dump and
> restore we still need to find something not violating the POLA.
>
> I think that would mean offering a backend function that list all files
> from a given extension and their content, including the control files,
> and a query that stores that output for only “inline” extensions. The
> content of the query result is formatted as a series of create extension
> and alter extension update (in the right order) in the dump file so that
> it just transparently re-creates the files for you on the new databse.
Hmm. But CREATE EXTENSION / ALTER EXTENSION doesn't seem right,
because the files in the directory correspond to *available*
extensions, not already-created ones. We need some way of dumping and
restoring the files themselves, not the extension that can be created
from them. I suspect internal functions (pg_whatever) make more sense
than new SQL syntax, since this is really only to make pg_dump happy.
> Or do you still want to insist that dump/restore shouldn't care about
> any extension, inline or not, and so you're given the responsibility to
> do the exact same thing yourself on the client side?
How about adding a new pg_dump option to suppress this part of the dump?
It seems to me that there will be people who want to do that; for
example, it might be that all (or some, or one) of the extensions that
were installed this way on the old server are installed globally on
the new server. We need some way to cope with that. Having a new
pg_dump option to suppress this output is not terribly granular but
maybe it'd be enough for round one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
