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