Re: WIP: Allow SQL-language functions to reference parameters by parameter name

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Hence the GUC.  Where's the issue?

> Behavior-changing GUCs for this kind of thing cause a lot of problems.
>  If you need one GUC setting for your application to work, and the
> extension you have installed needs the other setting, you're screwed.
> In the worst case, if a security-definer function is involved, you can
> create a security hole, for example by convincing the system that id =
> $1 is intended to mean $1 = $1, or some such.  You can of course
> attach the GUC settings to each individual function, but that doesn't
> really work either unless you do it for every function in the system.
> The fundamental problem here is that GUCs are dynamically scoped,
> while this problem is lexically scoped.

Yeah.  In the plpgsql case, we did make provisions to control the
behavior per-function.  In principle we could do the same for SQL
functions, but it'd be rather a PITA I think.  (In particular, the "easy
way out" of attaching SET clauses to the functions would be a bad idea
because it would defeat inlining.)

			regards, tom lane