Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> Problem solved! The only downside is that the use of this facility
> would have to be restricted to superusers, but the current consensus
> on this thread is that we should restrict *this* facility to
> superusers also, so we're not really losing anything. And, for a
> further plus, it'd even work for extensions that contain shared
> libraries. Win.
This is more-or-less what I've been argueing for when it comes to
addressing this for people who are superusers and want to install
.so's via libpq- do it outside of PG core, thank you very much.
> Now, if we could make this mechanism work for non-superusers, then I
> think it gets more interesting, because now you have a more
> significant gain in functionality: someone can potentially download an
> extension from PGXN and install it just for themselves without needing
> superuser access, provided the extension doesn't require a .so or any
> permissions that they don't have.
This is exactly what I want to see happen, with perhaps some external
tool which handles the "download from PGXN and install it" part- or
maybe we add that to psql, but I feel like a dedicated tool would be
better.
> That's kind of nice, but as Stephen
> said elsewhere on the thread, this seems like a lot of mechanism for
> that narrow goal. As you (I think) said somewhere on this thread, you
> could just create the extension with a bunch of CREATE and ALTER
> EXTENSION .. ADD statements and set a flag on it that causes it to be
> dumped the same way. (We might need to add a CREATE EXTENSION foo
> WITH NO CONTENTS statement to really make it work, so that the libpq
> connection can create it as completely empty and then add objects to
> it one at a time, but we shouldn't need too much more than that.) The
> whole idea of the extension template as such goes away.
Exactly.
Thanks,
Stephen