Subject: Re: Clarification on View Privileges and Operator Execution in PostgreSQL

From: "David G. Johnston" <[email-masked]>
Date: Sun, 7 Apr 2024 09:25:23 -0700

On Sun, Apr 7, 2024 at 9:10 AM Ayush Vatsa <[email-masked]> 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.

---

From: Ayush Vatsa <[email-masked]>
Date: Sun, 7 Apr 2024 22:02:21 +0530

> 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?

---

From: "David G. Johnston" <[email-masked]>
Date: Sun, 7 Apr 2024 09:37:46 -0700

On Sun, Apr 7, 2024 at 9:32 AM Ayush Vatsa <[email-masked]> wrote:

> > Now table x will be accessed (SELECT * FROM x) with
> "postgres" privileges but who will execute the
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.