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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: 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-11-15 04:21:16
Message-ID: a70db0888e52e2114c7840ce91f166a8c40b5c69.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-11-15 04:49:06 Re: Remove MSVC scripts from the tree
Previous Message Amit Kapila 2023-11-15 04:19:36 Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)