Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION } - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
Date
Msg-id a70db0888e52e2114c7840ce91f166a8c40b5c69.camel@j-davis.com
Whole thread Raw
In response to Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
List pgsql-hackers
On Mon, 2023-09-25 at 11:30 -0400, Robert Haas wrote:
> > That's what this whole thread is about: I wish it was reasonable,
> > but I
> > don't think the tools we provide today make it reasonable. You
> > expect
> > Bob to do something like:
> >
> >   CREATE FUNCTION ... SET search_path = pg_catalog, pg_temp ...
> >
> > for all functions, not just SECURITY DEFINER functions, is that
> > right?
>
> Yes, I do. I think it's self-evident that a SQL function's behavior
> is
> not guaranteed to be invariant under all possible values of
> search_path. If you care about your function behaving the same way
> all
> the time, you have to set the search_path.

After adding the search path cache (recent commit f26c2368dc) hopefully
that helps to make the above suggestion more reasonable performance-
wise. I think we can call that progress.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
Next
From: Michael Paquier
Date:
Subject: Re: Remove MSVC scripts from the tree