Access to dynamic SQL in PL/pgSQL
in [PgSql]
|
From: Simon Riggs on 22 Jan 2010 11:19 On Fri, 2010-01-22 at 10:56 -0500, Tom Lane wrote: > 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. 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 -- 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 11:33 Simon Riggs <simon(a)2ndQuadrant.com> writes: > 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. If you're talking about a bundle that you're shipping to customers, of course you can do whatever you want, since you can ensure that your plpgsql.so and your plugin are compatible. Stuff we release into the wide world doesn't have that luxury. We can't assume much more than what PG_MODULE_MAGIC will enforce for us, and that means ABI breaks within a major release series are dangerous. But to get back to the point, what have you got against adding another plugin call within the statements that build dynamic queries? It seems like a much cleaner solution to me, and not any different from the standpoint of back-portability. 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
From: Simon Riggs on 22 Jan 2010 11:59 On Fri, 2010-01-22 at 11:33 -0500, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > 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. > > If you're talking about a bundle that you're shipping to customers, > of course you can do whatever you want, since you can ensure that > your plpgsql.so and your plugin are compatible. > Stuff we release > into the wide world doesn't have that luxury. We can't assume much > more than what PG_MODULE_MAGIC will enforce for us, and that means > ABI breaks within a major release series are dangerous. Understood > But to get back to the point, what have you got against adding > another plugin call within the statements that build dynamic > queries? It seems like a much cleaner solution to me, and not > any different from the standpoint of back-portability. So a "dynamic query hook". When called, the hook would give access to the query text actually executed. Existing plugins wouldn't know about the hook, so would never call it, so the language run time would bypass that hook altogether. Newer versions of plugins would be able to decide whether to add-in code for the new hook based upon the version number. Neat solution, nothing against it at all. Would such a solution be backpatchable? I wasn't sure what your last sentence meant. -- 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 12:08 Simon Riggs <simon(a)2ndQuadrant.com> writes: > So a "dynamic query hook". When called, the hook would give access to > the query text actually executed. Existing plugins wouldn't know about > the hook, so would never call it, so the language run time would bypass > that hook altogether. Newer versions of plugins would be able to decide > whether to add-in code for the new hook based upon the version number. > Neat solution, nothing against it at all. > Would such a solution be backpatchable? I wasn't sure what your last > sentence meant. It doesn't seem backpatchable to me, because there is no mechanism beyond PG_MODULE_MAGIC that would ensure that plpgsql.so and the plugin have the same idea about the contents of struct PLpgSQL_plugin. In hindsight it might've been a good idea if that struct contained a version number, so if we're gonna change it I'd vote for adding one. What my previous comment was meant to say was that this approach doesn't seem practically different from the other as far as backwards compatibility goes. To wit: I don't think we can back-patch it in the community sources, but there is nothing stopping you from back-patching in a custom release where you have some confidence that compatible versions of plpgsql.so and plugin will be used together. 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
First
|
Prev
|
Pages: 1 2 Prev: [HACKERS] Access to dynamic SQL in PL/pgSQL Next: Standby server lagging behind |