From: | "Brendan Jurd" <direvus(at)gmail(dot)com> |
---|---|
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 17:36:41 |
Message-ID: | 37ed240d0709011036g2e56925bvece78a3de0bf638c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/2/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
There's a niceness to being able to tell Postgres everything it needs
to know about a function in the one CREATE FUNCTION command.
So if we integrated the GUC settings into CREATE FUNCTION, we'd end up
writing something like
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?
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.
Cheers,
BJ
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-09-01 17:48:55 | Re: Per-function search_path => per-function GUC settings |
Previous Message | Tom Lane | 2007-09-01 17:35:42 | Re: [PATCH] Lazy xid assingment V2 |