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
Re: Per-function search_path => per-function GUC settings |
Список | 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 по дате отправления: