Robert, * Robert Haas (robertmh...@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
signature.asc
Description: Digital signature