Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

From: Joe Conway <mail(at)joeconway(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
Date: 2023-09-25 20:11:18
Message-ID: 49d4652c-043b-eb73-264a-37843606f6a9@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/25/23 14:03, Jeff Davis wrote:
> On Mon, 2023-09-25 at 12:00 -0400, Joe Conway wrote:
>> Should there be a way to have a separate "execution" search_path?
>
> I hadn't considered that and I like that idea for a few reasons:
>
> * a lot of the problem cases are for functions that don't need to
> access tables at all, e.g., in an index expression.
> * it avoids annoyances with pg_temp, because that's not searched for
> functions/operators anyway
> * perhaps we could force the object search_path to be empty for
> IMMUTABLE functions?
>
> I haven't thought it through in detail, but it seems like a promising
> approach.

Related to this, it would be useful if you could grant create on schema
for only non-executable objects. You may want to allow a user to create
their own tables but not allow them to create their own functions, for
example. Right now "GRANT CREATE ON SCHEMA foo" gives the grantee the
ability to create "all the things".

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-09-25 20:19:22 Re: Eager page freeze criteria clarification
Previous Message Andres Freund 2023-09-25 19:48:30 Re: Performance degradation on concurrent COPY into a single relation in PG16.