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 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. Comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
