"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION foo(int) RETURNS int AS $$
> ...
> $$
> LANGUAGE plpgsql
> STABLE
> STRICT
> SECURITY DEFINER
> RESET search_path
> SET regex_flavor = 'cinnamon';
> That doesn't seem especially horrible. In what way do you feel it is
> inconsistent with existing syntax?
Hmm ... I hadn't thought of including SET in the syntax, so I was
running into problems with distingushing GUC variable names from the
keywords that are already in the syntax. That way would work from a
grammar point of view. It still seems a bit inconsistent to me, but
we could live with it. Comments anyone?
> And ... although I'll admit this is a paranoid thing to mention, if
> you have to fix the search_path setting *after* creating a function as
> SECURITY DEFINER, then there is necessarily a short period of time
> where the function exists and is insecure.
You already have that issue with respect to the default public execute
permissions on the function. The standard solution is to do it in a
transaction block --- then no one can even see the function until you
commit.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
