From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |
Date: | 2025-07-30 16:21:08 |
Message-ID: | 508f71c4-f1b1-4685-921d-bec8b361be10@aklaver.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/30/25 08:47, Dominique Devienne wrote:
> On Wed, Jul 30, 2025 at 5:23 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2025-07-30 19:42:39 | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |
Previous Message | Dominique Devienne | 2025-07-30 15:47:14 | Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function |