Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers