Pavel Stehule <pavel.stehule@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.