On Thu, Aug 16, 2018 at 03:46:06PM -0400, Robert Haas wrote:
> On Wed, Aug 15, 2018 at 3:17 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
> >> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > So you are saying PG functions should lock down their search path at
> >> > function definition time, and use that for all function invocations?
> >>
> >> Yes, mostly. I don't think we can just change the existing behavior;
> >> it would break a catastrophic amount of stuff. But we could add an
> >> optional feature that does this, and encourage people to use it, much
> >> the way Perl continues to support "local" even though "my" has been a
> >> best practice for several decades.
> >
> > So each function defines its search_path, and each function you call sets
> > its own search_path, basically? That is what you mean by lexical scope?
> > I think if this approach was fully secure, it would get more traction.
>
> By lexical scope, I mean a search_path that applies only to the SQL
> queries that textually appear within that function definition, not
> code that they call indirectly. The SET clause attached to a function
> uses dynamic scope. See
> https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scope_vs._dynamic_scope
I understand you don't like that a search_path changed by a function is
passed down to functions it calls, but what would you like the system to
use as a search path for called functions? The search path of the
session?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +