Re: Per-function search_path => per-function GUC settings

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

In response to

Responses

Browse pgsql-hackers by date

  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