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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Per-function search_path => per-function GUC settings
Дата
Msg-id 22752.1188669950@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Per-function search_path => per-function GUC settings  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Per-function search_path => per-function GUC settings  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> I think security definer functions should automatically inherit their
> search_path. The whole "secure by default" thing.

This assumes that the search path at creation time has something to do
with the path you'd like to use at execution, which is unlikely to be
the case in existing pg_dump output, to name one example.  I don't
really want to get into doing the above.

> It might be best to have a guc variable which controls the variables which are
> automatically saved. regexp_flavour and maybe a handful of others could be in
> it by default. But that might depend on how expensive it is at run-time. I
> wouldn't want trivial SQL functions to no longer be inline-able because one
> might one day use a regexp for example.

Well, security definer functions can't be inlined anyway, so as long as
you only try to do this for sec-def functions it wouldn't be an issue.
I just think it's too big a departure from existing behavior, and will
probably break more things than it fixes.
        regards, tom lane


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

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