Re: Access to dynamic SQL in PL/pgSQL
От | Simon Riggs |
---|---|
Тема | Re: Access to dynamic SQL in PL/pgSQL |
Дата | |
Msg-id | 1264179587.4043.15727.camel@ebony обсуждение исходный текст |
Ответ на | Re: Access to dynamic SQL in PL/pgSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Access to dynamic SQL in PL/pgSQL
|
Список | pgsql-hackers |
On Fri, 2010-01-22 at 11:33 -0500, Tom Lane wrote: > Simon Riggs <simon@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
В списке pgsql-hackers по дате отправления: