Re: search_path vs extensions

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?
*brainstorming*

...Robert