public inbox for [email protected]help / color / mirror / Atom feed
Re: Clarification on View Privileges and Operator Execution in PostgreSQL 3+ messages / 2 participants [nested] [flat]
* Re: Clarification on View Privileges and Operator Execution in PostgreSQL @ 2024-04-07 16:25 David G. Johnston <[email protected]> 2024-04-07 16:32 ` Re: Clarification on View Privileges and Operator Execution in PostgreSQL Ayush Vatsa <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: David G. Johnston @ 2024-04-07 16:25 UTC (permalink / raw) To: Ayush Vatsa <[email protected]>; +Cc: [email protected] On Sun, Apr 7, 2024 at 9:10 AM Ayush Vatsa <[email protected]> wrote: > > but what about the view which contains inbuilt operators or inbuilt > functions with whose privileges those will be executed. Eg. > From the create view documentation: Functions called in the view are treated the same as if they had been called directly from the query using the view. Therefore, the user of a view must have permissions to call all functions used by the view. Functions in the view are executed with the privileges of the user executing the query or the function owner, depending on whether the functions are defined as SECURITY INVOKER or SECURITY DEFINER. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Clarification on View Privileges and Operator Execution in PostgreSQL 2024-04-07 16:25 Re: Clarification on View Privileges and Operator Execution in PostgreSQL David G. Johnston <[email protected]> @ 2024-04-07 16:32 ` Ayush Vatsa <[email protected]> 2024-04-07 16:37 ` Re: Clarification on View Privileges and Operator Execution in PostgreSQL David G. Johnston <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Ayush Vatsa @ 2024-04-07 16:32 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: [email protected] > Functions in the view are executed with the privileges of the user executing the query or the function owner So does that imply to the function associated with the operators (both builtin and user defined) too. Basically wanted to know about this - > Now table x will be accessed (SELECT * FROM x) with "postgres" privileges but who will execute the > underlying function inside the ( > ) operator ? Is it postgres or alex? On Sun, 7 Apr 2024 at 21:56, David G. Johnston <[email protected]> wrote: > On Sun, Apr 7, 2024 at 9:10 AM Ayush Vatsa <[email protected]> > wrote: > >> >> but what about the view which contains inbuilt operators or inbuilt >> functions with whose privileges those will be executed. Eg. >> > > From the create view documentation: > Functions called in the view are treated the same as if they had been > called directly from the query using the view. Therefore, the user of a > view must have permissions to call all functions used by the view. > Functions in the view are executed with the privileges of the user > executing the query or the function owner, depending on whether the > functions are defined as SECURITY INVOKER or SECURITY DEFINER. > ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Clarification on View Privileges and Operator Execution in PostgreSQL 2024-04-07 16:25 Re: Clarification on View Privileges and Operator Execution in PostgreSQL David G. Johnston <[email protected]> 2024-04-07 16:32 ` Re: Clarification on View Privileges and Operator Execution in PostgreSQL Ayush Vatsa <[email protected]> @ 2024-04-07 16:37 ` David G. Johnston <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: David G. Johnston @ 2024-04-07 16:37 UTC (permalink / raw) To: Ayush Vatsa <[email protected]>; +Cc: [email protected] On Sun, Apr 7, 2024 at 9:32 AM Ayush Vatsa <[email protected]> wrote: > > Functions in the view are executed with the privileges of the user > executing the query or the function owner > So does that imply to the function associated with the operators (both > builtin and user defined) too. > Basically wanted to know about this - > > Now table x will be accessed (SELECT * FROM x) with > "postgres" privileges but who will execute the > > underlying function inside the ( > ) operator ? Is it postgres or alex? > >> >> An operator is a function invocation with special syntax. So I expect that sentence to apply. If you want to confirm what the documentation says create a custom operator/function that alex is not permitted to execute and have them query a view defined by postgres that uses that function. David J. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-04-07 16:37 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-04-07 16:25 Re: Clarification on View Privileges and Operator Execution in PostgreSQL David G. Johnston <[email protected]> 2024-04-07 16:32 ` Ayush Vatsa <[email protected]> 2024-04-07 16:37 ` David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox