Robert Haas <robertmhaas@gmail.com> writes:
> I am pretty concerned that we find a design that does not involve
> pg_dump needing to dump out the extension contents, though: that seems
> to me to be missing the point of having extensions in the first place.
I was just trying to explain where I'm coming from, I'm not wedded to
the idea though, all the more when I think that we're reaching a much
better one.
>> I think Cédric nailed it down upthread, proposing that we just use a
>> PGDATA sub directory called 'pg_extension'. In fact, that would need to
>> be a per-database sub directory. Then there's nothing to setup, nothing
>> to abuse.
>
> Hmm, that might have something going for it. It seems comparatively
> easy to implement, and it also seems to do a pretty good job hiding
> the complexity under the hood where users don't have to worry about
> it.
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.
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?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
