* Robert Haas (robertmh...@gmail.com) wrote: > 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.
I'm not convinced we really need to solve that problem, but one way to
solve it 'cleanly' would be to seperate the two types of extensions,
perhaps by calling them by different names or inventing a namespace for
extensions.
> 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.
I think we're falling into the trap of thinking that whatever this
user-installable-collection-of-objects thing is, it must be considered
PG 'extensions'. While I agree that some of the things we do for
extensions should also be done with these collections of objects (eg:
having versions and other meta-data for them), I'm starting to think
that's the "small" side of this whole equation and duplicating that
meta-data store for these collections would be easier than trying to
shoehorn them into the existing notion of 'extensions'.
Thanks,
Stephen
signature.asc
Description: Digital signature
