From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Per-function search_path => per-function GUC settings |
Date: | 2007-09-01 22:52:29 |
Message-ID: | 20070901225229.GA19705@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote:
> I believe we had consensus that 8.3 needs to include an easier way for a
> function to set a local value of search_path, as proposed here:
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php
> I've been holding off actually implementing that because adding a column
> to pg_proc would create merge problems for pending patches. But tsearch
> was the last one with any major changes to pg_proc.h, so it's probably
> time to get on with it.
>
> A few days ago, Simon suggested that we should generalize this notion
> to allow per-function settings of any GUC variable:
> http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php
> My reaction to that was more or less "D'oh, of course!" Stuff like
> regex_flavor can easily break a function. So rather than thinking
> only about search_path, it seems to me we should implement a facility
> that allows function-local settings of any USERSET GUC variable, and
> probably also SUSET ones if the function is SECURITY DEFINER and owned by
> a superuser.
>
> The most straightforward way to support this syntactically seems to
> be to follow the per-user and per-database GUC setting features:
>
> ALTER FUNCTION func(args) SET var = value
Would it be hard to extend this into this?
ALTER FUNCTION func(args) SET var = value [, var = value ...]
> ALTER FUNCTION func(args) RESET var
>
> The RESET alternative is a lot cleaner than my previous suggestion
> of "PATH NONE" to remove a non-default path setting, anyway.
>
> I thought about ways to include GUC settings directly into CREATE
> FUNCTION, but it seemed pretty ugly and inconsistent with the
> existing syntax. So I'm thinking of supporting only the above
> syntaxes, meaning it'll take at least two commands to create a
> secure SECURITY DEFINER function.
With the extended syntax I proposed it could take just one command to
create such a function :)
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-01 23:44:26 | Re: Per-function search_path => per-function GUC settings |
Previous Message | Marko Kreen | 2007-09-01 22:37:35 | Re: Per-function search_path => per-function GUC settings |