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 = valueALTER 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.
Comments?
regards, tom lane