Re: Access to dynamic SQL in PL/pgSQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Access to dynamic SQL in PL/pgSQL
Date
Msg-id 2934.1264180084@sss.pgh.pa.us
Whole thread Raw
In response to Re: Access to dynamic SQL in PL/pgSQL  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: psql tab completion recently broken?
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode