Re: Loading the PL/pgSQL debugger (and other plugins) - Mailing list pgsql-hackers

<br /><blockquote cite="mid700.1153506529@sss.pgh.pa.us" type="cite"><blockquote type="cite"><blockquote
type="cite"><prewrap="">When the plugin's shared library gets loaded, one way or the other,
 
it should construct the function-pointer struct and then pass it to a
function defined by plpgsql (this lets us hide/postpone the decision
about whether there can be more than one active plugin).
     </pre></blockquote><pre wrap="">But there's a timing issue there.  If you ask the plugin to call a 
call-handler function, then you can't load the plugin at backend startup 
because the PL/pgSQL call-handler isn't loaded until it's required.  
Since both the plugin and the call-handler are dynamically loaded, I 
think one of them has to load the other.   </pre></blockquote><pre wrap="">
Right, but if you set up the mechanism such that each individual PL is
responsible for loading plugins, then we'll have to duplicate all that
code each time we instrument another PL.  I want to do as much as
possible of the work in the core code so that we don't end up with
duplicate code to maintain. </pre></blockquote> I think I'm missing something important here.  <br /><br /> At minimum,
youneed a way to identify a plugin (or a list of plugins), and, if we generalize the mechanism, a way to identify the
languagethat that plugin is associated with (like, this profiler works with PL/tcl, this debugger works with PL/Java,
...).<br/><br /> Once you have that, you've got two choices: <br /><br /> 1) The plugin loads the language<br />    
   or<br /> 2) The language loads the plugin<br /><br /> You are suggesting option 1.  That means that we must:<br
/><br/><blockquote>a) come up with a way to identify the set of plugins desired (probably some GUC variables?)<br /> b)
Extendthe pg_language structure<br /> c) Extend the CREATE LANGUAGE statement<br /> d) come up with a way for the
backendto load the plugins (the backend already knows how to load a language-handler)<br /> e) add loader code to each
plugin(there should be more plugins than languages eventually)<br /> f) add loader code to each language (at least each
languagethat wants to support a plugin)<br /></blockquote><br /> On the other hand, if the language loads the plugin,
wemust:<br /><br /><blockquote>a) come up with a way to identify the set of plugins desired (probably some GUC
variables?)<br/> b) add loader code to each plugin<br /> c) add loader code to each language (that wants to support a
plugin)<br/></blockquote><br /> In either case, the loader code in the language-handlers and the loader code in the
pluginscould be simple calls to common functions that are defined in the core, avoiding a lot of duplicate code. For
example,each language handler (in it's initialization code) could include a call such as:<br /><br />    
pl_load_plugins("pl/pgsql", &functionPointers );<br /><br /> or<br /><br />     pl_load_plugins( "pl/java",
&functionPointers);<br /><br /> pl_load_plugins() would reside in the core, it would find the list of plugins, load
eachone, find the plugin's initialization function, and call that function with &functionPointers (the initializer
wouldfill in the functionPointers structure).<br /><br /> So what am I missing?  What's the advantage to having the
pluginload the language?<br /><br /><blockquote cite="mid700.1153506529@sss.pgh.pa.us" type="cite"><pre wrap="">
 
To do it without a pg_language column, we'd need code in each plugin to
identify the language shared library (by looking in pg_language), force
loading of same (using existing fmgr code), and look up and call a
plugin receptor function given an expected C-code name for it (again,
most of this already exists in fmgr).  It's not a huge amount of code,
probably, but again duplicating it in each plugin seems unappealing.
I suppose we could make fmgr export a general function to find a plugin
receptor function given the PL name and the expected C symbol. </pre></blockquote> That's what I was thinking too.  But
wecould avoid hard-coded names using a syntax similar to preload_libraries (each entry in preload_libraries can contain
thename of an optional initialization function).  If you specify libraryName:functionName, we would assume that
functionNamewas the loader function, if you just specify libraryName, we could look for a hard-coded default.<br /><br
/><br/> (Oh, and any more comments on security?  Is it enough to require that all plugins live in $libdir?)<br /><br />
         -- Korry<br />