Access to dynamic SQL in PL/pgSQL
in [PgSql]
|
From: Pavel Stehule on 22 Jan 2010 05:41 2010/1/22 Simon Riggs <simon(a)2ndquadrant.com>: > > 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. can you show some example, please? Pavel > > 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. > > Would a patch to make this simple change be acceptable? It would need to > be backpatched to 8.1 also? > > -- >  Simon Riggs      www.2ndQuadrant.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 22 Jan 2010 06:00 On Fri, 2010-01-22 at 11:41 +0100, Pavel Stehule wrote: > 2010/1/22 Simon Riggs <simon(a)2ndquadrant.com>: > > > > 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. > > can you show some example, please? exec_stmt_dynexecute() evaluates querystr at start and pfrees it before end of exec_stmt_dynexecute(). So plugin never gets to see the SQL executed. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 22 Jan 2010 06:39 Simon Riggs wrote: > 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. Is this for pl/debugger? How would you use the query string there? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 22 Jan 2010 06:54 On Fri, 2010-01-22 at 13:39 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > 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. > > Is this for pl/debugger? How would you use the query string there? Yes, PL/debugger would have access to the text of the dynamic SQL string. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 22 Jan 2010 10:56 Simon Riggs <simon(a)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. 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. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] Access to dynamic SQL in PL/pgSQL Next: Standby server lagging behind |