On Fri, May 29, 2009 at 5:45 PM, Greg Stark <st...@enterprisedb.com> wrote: > On Fri, May 29, 2009 at 10:26 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
