Re: Access to dynamic SQL in PL/pgSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Access to dynamic SQL in PL/pgSQL
Date: 2010-01-22 17:08:04
Message-ID: 2934.1264180084@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2010-01-22 17:11:51 Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Previous Message Kevin Grittner 2010-01-22 17:07:34 Re: psql tab completion recently broken?