Re: Extension Templates S03E11 - Mailing list pgsql-hackers

On Mon, Dec 2, 2013 at 3:17 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> What I've been trying to point out is that there's absolutely zero need
>> for the 'extension template' part of this to make a pg_restore work for
>> an entirely-in-the-catalog extension.  I realize that's how you've done
>> it with this patch set but that doesn't make it necessary.
>
> If it's an extension, it's filtered out of pg_dump, so it's not part of
> your pg_restore. Full Stop. This point has been debated and there has
> been a very clear conclusion a year ago.
>
> What am I missing here?

This is a fair point.  For those that may not remember the previous
proposal, see here:

http://www.postgresql.org/message-id/m2390abpc1.fsf@2ndQuadrant.fr

See also ensuing discussion.

Speaking only for myself, I think the thing I most disliked about that
proposal was the syntax.  I'd rather see each extension member dumped
separately, and then later dump the extension itself as CREATE
EXTENSION ... WITH NO CONTENTS or similar followed by ALTER EXTENSION
... ADD <item> for each member.  That would provide a way of handling
dependency loops, which Dimitri's proposed syntax did not, and just in
general seems more elegant.  But it's not perfect: for example,
there's no clean way to handle the situation where the extension is
present in the filesystem on the old database but not the new, or
visca versa, and I don't think anyone's proposed *any* really clean
way of handling that yet.

Fundamentally, I think this is a pretty hard problem.  The OS-level
equivalent of extensions is something like RPMs or .deb files, and I
can't help but observe that those are only used for system-wide
installations, not per-user installs.  I think the reason we're having
a hard time coming up with a satisfactory way of making this work is
that an extension as installed from SQL using libpq is a pretty
different beast from an extension as installed via the filesystem, and
bending the existing mechanism to make that work is somewhat painful
no matter how you do it.  The argument was made then, and with some
validity, that we just shouldn't make the same mechanism serve both
purposes.  What I now understand (that I think I probably didn't fully
understand back then) is that part of the point here is to enable
installation of extensions without requiring local filesystem access;
using a completely different mechanism would defeat that goal.  But
I'm still not altogether happy with where that's landed us.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company