Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
От | Adrian Klaver |
---|---|
Тема | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |
Дата | |
Msg-id | 508f71c4-f1b1-4685-921d-bec8b361be10@aklaver.com обсуждение исходный текст |
Ответ на | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function (Dominique Devienne <ddevienne@gmail.com>) |
Ответы |
Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
|
Список | pgsql-general |
On 7/30/25 08:47, Dominique Devienne wrote: > On Wed, Jul 30, 2025 at 5:23 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote: >> On 7/30/25 04:37, Dominique Devienne wrote: >>> Are there special consideration I'm unaware of, regarding SET ROLE >>> inside routines? > >> What is the ROLE that defined the function? > > A 3rd role. But does it matter? Given that this is in SECURITY INVOKER function? My mistake, a BC(Before Coffee) issue. > The function and the table belong to yet another role. > And when we enter the function, we're yet another one (obviously with > USAGE+EXECUTE, since could call it). > But once we SET LOCAL ROLE, the effective permissions used should be > for :OWNER1 and the inherited :SOWNER. Could this be a search_path and/or naming issue, where the table SchemaMapping appears in more then one schema or different name case? -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: