On Fri, May 29, 2009 at 5:45 PM, Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Fri, May 29, 2009 at 10:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> This sounds quite horrid to me. The way programming languages solve
>> this problem is they have a flag that either makes certain names not
>> visible from other namespaces, or they provide explicit control over
>> which names get exported.
> There are two factors which distinguish this situation from most
> programming languages:
> 1) Hopefully these languages you're thinking of are lexically scoped.
> So the search path in effect when the objects are defined decide which
> other objects they reference. In Postgres in many cases we're
> effectively dynamically scoped. If someone calls us with another
> search path we'll pick up other objects we weren't expecting.
> 2) Normally programming languages do early binding so as soon as the
> code is parsed references are resolved. You can't later define a new
> function earlier in the search path and have it take over references
> that have were previously referring to some other function.
Good point. But maybe there's some way of getting some kind of
behavior that is closer to lexical scoping/early binding? Because the
way it works right now has lousy security implications, beyond being
difficult for search_path management. Assign a search path to a
schema, that applies to views and functions defined therein?
In response to
pgsql-hackers by date
|Next:||From: James Pye||Date: 2009-05-29 22:43:05|
|Subject: Re: Python 3.0 does not work with PL/Python|
|Previous:||From: Greg Smith||Date: 2009-05-29 22:16:21|
|Subject: Re: search_path vs extensions|