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

korry <korryd@enterprisedb.com> writes:
> I'm working on a patch that implements the PL/pgSQL instrumentation 
> stuff (i.e. the PL/pgSQL debugger)  that I discussed at the Anniversary 
> Summit and I need some opinions (this seems like a good place to look 
> for opinions :-)

Opinions R US ;-)

> 1) I think the most straightforward way to load an instrumentation 
> plugin is to define a new custom GUC variable (using the 
> custom_variable_classes mechanism).

This seems a bit messy and special-purpose.  I see no good reason to tie
it to plpgsql; we'll just need another one for every other language.
IMHO what we want is something with similar properties to preload_libraries,
but processed on a per-backend basis instead of once at postmaster start.
(You could almost just tell people to select the plugin they want by
LOADing it, but that is hard to use if you're trying to debug a
non-interactive application.  A GUC variable can be set for an app
without much cooperation from the app.)

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).

One issue that needs to be thought about with either this proposal or
your original is what permissions are needed to set the GUC variable.
I don't think we dare allow non-superusers to specify LOADing of
arbitrary shared libraries, so there has to be some filter function.

Perhaps a better way is that the GUC variable specifies a (list of)
initialization functions to call at backend start, and then the
superuserness is involved with installing the init functions into
pg_proc, and the GUC variable itself needs no special permissions.
Again, a plugin's init function would just register its function-pointer
struct with plpgsql.

We should also think about a deregistration function.  This would allow
you to turn debugging on and off within an interactive session.  The
GUC variable is really only for coercing non-interactive applications
into being debuggable --- I don't see it as being important for
interactive debugging, as compared to just "select plugin_init();" ...

> 3) Any comments on the PLpgSQL_plugin structure?  Should it include (as 
> it's first member) a structure version number so we can add to/change 
> the structure as needed?

Given our current plans for enforcing recompiles at major version
changes (via magic-block checking), I'm not sure I see a need for this.

> 4) Do we need to support multiple active plugins?

Probably, but let's fix the API to hide this, so we don't have to commit
now.
        regards, tom lane