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
notappear 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
solvethe 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
gotthe enumerated somewhere?
>> And if so, then they could be distributed as extensions with superuser = true?
>
> Right.
Great, thanks!
David
