Robert, * Robert Haas ([email protected]) 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
signature.asc
Description: Digital signature
