Re: Per-function search_path => per-function GUC settings

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Re: Per-function search_path => per-function GUC settings
Дата
Msg-id 37ed240d0709011036g2e56925bvece78a3de0bf638c@mail.gmail.com
обсуждение исходный текст
Ответ на Per-function search_path => per-function GUC settings  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Per-function search_path => per-function GUC settings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Per-function search_path => per-function GUC settings  (John DeSoi <desoi@pgedit.com>)
Список pgsql-hackers
On 9/2/07, Tom Lane <tgl@sss.pgh.pa.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 plpgsqlSTABLESTRICTSECURITY DEFINERRESET search_pathSET 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Lazy xid assingment V2
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Per-function search_path => per-function GUC settings