Skip site navigation (1) Skip section navigation (2)

Re: search_path vs extensions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: search_path vs extensions
Date: 2009-05-29 22:18:08
Message-ID: 603c8f070905291518t57ce5dc5j1b99923a1b131505@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: James PyeDate: 2009-05-29 22:43:05
Subject: Re: Python 3.0 does not work with PL/Python
Previous:From: Greg SmithDate: 2009-05-29 22:16:21
Subject: Re: search_path vs extensions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group