On Mar 3, 2011, at 2:16 PM, Tom Lane wrote: > 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.
Ah, I see. So if someone installed a PL with CREATE LANGUAGE and my extension requires that, PL, the requirement will not appear to be fulfilled. Kind of a bummer. Maybe add a note to CREATE LANGUAGE suggesting the use of CREATE EXTENSION, instead? Or perhaps createlang could be made to create the extension instead? That would probably mostly solve the problem. > 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. Makes sense. > 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. That sounds like a decent plan. I can see we're getting a number of To-Dos for 9.2 out of the extension work. Someone got the enumerated somewhere? >> And if so, then they could be distributed as extensions with superuser = >> true? > > Right. Great, thanks! David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
