Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function - Mailing list pgsql-general

From Adrian Klaver
Subject Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Date
Msg-id 508f71c4-f1b1-4685-921d-bec8b361be10@aklaver.com
Whole thread Raw
In response to Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
List 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 by date:

Previous
From: Dominique Devienne
Date:
Subject: Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function
Next
From: Adrian Klaver
Date:
Subject: Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function