Re: Quick Extensions Question
От | Tom Lane |
---|---|
Тема | Re: Quick Extensions Question |
Дата | |
Msg-id | 8677.1299190596@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Quick Extensions Question ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: Quick Extensions Question
|
Список | pgsql-hackers |
"David E. Wheeler" <david@kineticode.com> writes: > On Mar 3, 2011, at 1:31 PM, Tom Lane wrote: >> 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 youDROP LANGUAGE? Extensions yes, but not managed with those commands. You'd have to switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE commands themselves would now only occur within those extension scripts. BTW, a fine point I didn't mention in the previous summary is that if CREATE LANGUAGE within an extension script creates language support functions pursuant to what it finds in pg_pltemplate, those functions should be marked as belonging to the extension, so that they'd get dropped during DROP EXTENSION. I'm not sure whether the path of control is such that that'd happen today, but if it doesn't we'd need to tweak things. > I assume that non-core PLs must be installed by a superuser? Right. That's true already, because only a superuser can do the unvetted 'CREATE FUNCTION ... LANGUAGE c' commands that are necessary for installing a PL not known to pg_pltemplate. I would like to get rid of pg_pltemplate eventually (in favor of trusting commands coming from an extension script), but we're not there yet. > And if so, then they could be distributed as extensions with superuser = true? Right. regards, tom lane
В списке pgsql-hackers по дате отправления: