2014/1/4 Tom Lane <t...@sss.pgh.pa.us> > Pavel Stehule <pavel.steh...@gmail.com> writes: > > I propose a enhance the PLpgSQL_plugin struct by a new hook > > void (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma > > *pragma_stmt) > > I repeat what I said a couple of days ago: it's a very bad idea to be > enabling more plpgsql plugins as long as the infrastructure can only > support one. We need to fix that *first* before we go merrily designing > more. >
It means a some additional mechanism to find_rendezvous_variable. What about two new rendezvous variables? One for publishing a PLpgSQL internal API, and second a list of plpgsql_plugin structures? It would be very nice, if we can better access to other plpgsql public functions. A implementation in plpgsql_lint and plpgsql_check is working, but I agree so it is ugly designed (with some disadvantages) - and any change can be better. I minimize these bad references to plpgsq - but plpgsql requires "plpgsql_compile" and "plpgsql_parser_setup" still. Other possibility is new V1 function for plugin registration. > > I don't like the notion of a pragma statement in this form anyway, > because you've essentially made it an executable statement; usually > pragmas are compile-time things. It appears to me that you've basically > commandeered the word "pragma" for "SET affecting a plugin's variable". > It should not be named pragma - I have not better name now. It should not be used as plugin's variable primary. It should to invoke a external routine - with or without additional parameters. When I would to support tracking, then user should to explicitly set point, where tracking is defined - same is with assertions. > If we're inventing new callbacks for plugins, why not one that will extend > an existing statement having the right kind of semantics? yes, it is possible - I can to image some like PERFORM assert(exprlist) and inside callback, we can check a expression and when we find a expected pattern, we can change a semantic. I plan to use this workaround for first plpgsql dumper and tracking extension. But it can have some performance (probably minimal) impact - and it is difficult to implement a mode when this functionality is disabled without any performance impact. So special statement can simplify life to plugin' developers. > Or actually, > why would it not be better for the plugin to be using a custom GUC for > its variable? There's a large amount of infrastructure that custom GUCs > can take advantage of, which you'd otherwise have to reinvent piece > by piece. > GUC doesn't help me with marking some position in source code important for plugin. Regards Pavel > > regards, tom lane >
