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

On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Now, when this person attempts to recreate this function on a
>> hypothetical version of PostgreSQL that thinks "id" is ambiguous, it
>> doesn't work.
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company