Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
