2011/4/9 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.)
what about a new language like SQLc? - like SQL compatibility.
pg_upgrade can move old code into this compatibility language when
detect some posible problems.
Pavel
>
> 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
>