On Fri, 2010-01-22 at 10:56 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> > statement using a PL/pgSQL plugin.
>
> > In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> > statement type, evaluate the SQL and free memory again before the plugin
> > gains control again.
>
> > It seems simple to attach querystr to PLpgSQL_execstate and free it
> > after the plugin has seen it. The difference in lifetime of the memory
> > allocation is very small.
>
> That seems like a complete crock --- you're talking about leaving a
> dangling pointer to transient data in a permanent data structure.
No, I wouldn't call it that. You read the bit where I said "free"?
> In most contexts it would be difficult to be sure if the pointer was
> valid or not.
>
> If we need this it would be better to provide another plugin hook call
> during the execution of a statement that uses a dynamic query.
>
> > Would a patch to make this simple change be acceptable? It would need to
> > be backpatched to 8.1 also?
>
> As for the first, I vote "not like that", and as for backpatching,
> you're out of your mind.
I think by most people's standards asking for acceptance here really is
insane, I agree.
> This would be an incompatible ABI change,
> and we don't lightly make those in stable branches. Even if we were
> willing to take the risk, how would a plugin know if it were dealing
> with a version of plpgsql that had this field?
ISTM there are ways though I think what you mean is that they would be
unpalatable.
Anyway, there already was another way of doing this, so it shall be done
that way instead. The beauty of a pluggable architecture is that one
does not need approval to implement customer solutions.
-- Simon Riggs www.2ndQuadrant.com