Re: Access to dynamic SQL in PL/pgSQL
От
Simon Riggs
Тема
Re: Access to dynamic SQL in PL/pgSQL
Дата
Msg-id
1264177195.4043.15517.camel@ebony
Ответ на
Re: Access to dynamic SQL in PL/pgSQL (Tom Lane)
Список
Дерево обсуждения
Access to dynamic SQL in PL/pgSQL Simon Riggs <simon@2ndQuadrant.com>
Re: Access to dynamic SQL in PL/pgSQL Tom Lane <tgl@sss.pgh.pa.us>
Re: Access to dynamic SQL in PL/pgSQL Simon Riggs <simon@2ndQuadrant.com>
Re: Access to dynamic SQL in PL/pgSQL Tom Lane <tgl@sss.pgh.pa.us>
Re: Access to dynamic SQL in PL/pgSQL Simon Riggs <simon@2ndQuadrant.com>
Re: Access to dynamic SQL in PL/pgSQL Tom Lane <tgl@sss.pgh.pa.us>
Re: Access to dynamic SQL in PL/pgSQL Pavel Stehule <pavel.stehule@gmail.com>
Re: Access to dynamic SQL in PL/pgSQL Simon Riggs <simon@2ndQuadrant.com>
Re: Access to dynamic SQL in PL/pgSQL Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: Access to dynamic SQL in PL/pgSQL Simon Riggs <simon@2ndQuadrant.com>
On Fri, 2010-01-22 at 10:56 -0500, Tom Lane wrote: > Simon Riggs 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
В списке pgsql-hackers по дате отправления
От: Robert Haas
Дата: