From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Controlling changes in plpgsql variable resolution |
Date: | 2009-10-21 20:05:46 |
Message-ID: | 4ADF699A.3010300@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/21/09 1:02 PM, Josh Berkus wrote:
>> That's what the #option alternative is for. Yes, it's a bit ugly, but
>> it's perfectly functional, and secure too.
>
> I still don't see why it's needed. If the function owner simply sets
> the option in the function definitions (as a userset), it doesn't matter
> what the calling user sets, does it?
>
> All that's needed is a scripting example to set this in all function
> definitions as a regular setting.
Actually, to follow this up: there would be *huge* utility in ALTER
FUNCTION name SET setting=value statement. This would help people do
all the "lock down" things we want to do with function definitions.
There'd also be utility in a default set of guc settings for new
functions, but maybe we should put that off ...
--Josh
From | Date | Subject | |
---|---|---|---|
Next Message | Samuel ROZE | 2009-10-21 20:06:18 | Re: URL Managment - C Function help |
Previous Message | Heikki Linnakangas | 2009-10-21 20:02:43 | Re: Hot standby, prepared xacts, locks |