On Sat, 2007-09-01 at 12:41 -0400, Tom Lane wrote:
> 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
>
I was hoping this feature would make it easier for modules to install
into any schema. Right now a module can either preprocess a SQL install
script to install it into the schema you want, or hard-code the schema
into the file and you're stuck with whatever schema the module authors
chose (usually either the module name, or "public").
Can we also provide syntax which would be equivalent to setting "var"
for the function to be whatever the current value happens to be when the
ALTER FUNCTION is run? Possible syntax might be something like:
ALTER FUNCTION func(args) SET var TO CURRENT;
> 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.
That seems a little awkward, because to avoid a security race condition,
you'd have to wrap the CREATE/ALTER in a transaction block. However, we
already have a similar situation with creating a security definer
function and then revoking access, so maybe it's already expected.
I don't have a strong opinion, I just wanted to bring that up.
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
