From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Date: | 2011-04-08 23:30:26 |
Message-ID: | 21080.1302305426@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | bricklen | 2011-04-08 23:51:09 | Re: pg_upgrade bug found! |
Previous Message | Alvaro Herrera | 2011-04-08 23:20:53 | Re: lowering privs in SECURITY DEFINER function |