Robert Haas <robertmhaas@gmail.com> writes:
> 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,
I could have fixed the syntax quite easily, within 9.3 time frame.
> 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.
Well, my memories is that I did propose thinking about upgrade paths
mixing template sources, and Tom objected quite strongly to doing that.
IIRC the line of thoughs is that it's indeed a very complex problem to
solve, and renaming the extension when you switch your distribution
model might be all you need. Same with incompatible major versions, when
there's no integrated upgrade path possible.
> 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
If you want to dive into system level unprivileged package management,
have a look at that:
http://www.gnu.org/software/guix/
> 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'd like to better understanding what is so wrong about the current
design in terms that I'm not feeling like we did address a year ago.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support