On Mar 3, 2011, at 1:31 PM, Tom Lane wrote: > However, it does strike me that there is one simple case we could > support without a great deal of sweat. Namely, what if we allow > non-superusers to create an extension if all the commands in the script > are ones they could execute anyway? In particular, an extension > containing only CREATE LANGUAGE would work for exactly those users > who could execute CREATE LANGUAGE under the existing dispensations. > This might also make it less painful to use extensions that consist > purely of SQL (no underlying C functions).
Now see here? THAT's what I'm talking about! > This looks like it would be at most a few hours' work to change, > and it would enable creation of extensions for the built-in languages > that can be loaded with the same permissions as before. Would that time include having extension records for the core PLs, created when you CREATE LANGUAGE and removed when you DROP LANGUAGE? > It would > not do anything towards allowing non-superusers to load languages that > aren't listed in pg_pltemplate, but it doesn't make things any worse > for non-core languages either: they can make extensions that are > superuser-loadable, which is the same permissions situation they are > in now. > > Comments? I assume that non-core PLs must be installed by a superuser? And if so, then they could be distributed as extensions with superuser = true? I think this is awesome. Love it, especially for SQL-only extensions (of which I expect there will be many in the coming years). Of course, this doesn't address how to make compile-time options pre-requisites, but I think that's a somewhat less important issue, frankly. I can modify the explanation extension install script to throw an exception of xpath isn't installed, for example. Kind of a PITA, but do-able. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
