Re: proposal: extensible plpgsql executor - related to assertions

2014/1/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>