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

2011/4/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.)

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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>