Re: search_path improvements - Mailing list pgsql-hackers
From | David E. Wheeler |
---|---|
Subject | Re: search_path improvements |
Date | |
Msg-id | CC366B5F-F7BB-49E9-9292-CD70C56061D5@kineticode.com Whole thread Raw |
In response to | Re: search_path improvements (Greg Stark <stark@enterprisedb.com>) |
List | pgsql-hackers |
On May 31, 2009, at 3:47 PM, Greg Stark wrote: > On Sun, May 31, 2009 at 9:12 PM, Josh Berkus <josh@agliodbs.com> > wrote: >> This assumes that all users should have access to the same public >> APIs as >> all other users. Real applications are more complex. > > Well the goal is to make them simpler. I don't know any language that > has implemented what you describe. Either you have access to the > internal methods of a class or you don't and you only have access to > the public api. That seems to work for much more sophisticated > languages than ours just fine. Right, but PostgreSQL isn't a language, it's a database. And PostgreSQL already has stuff in place to affect visibility of objects. Such is not reasonable for Python, but makes perfect sense in an RDBMS IMHO. > Well when you ls a directory or perform some operation on a file you > only work with what's in that directory, not everything in the > hierarchy. I don't see how this relates to what Josh said. He was just talking about organizing object into schemas, not about trees of schemas AFAICT. > I don't think that gets any easier with better tools. This is the same > reason unix systems don't put every tool in a different directory and > then insist you put every directory in your path based on which tools > each user should have access to. But they have tools in a few different directories (/bin, /sbin, /usr/ bin, /usr/sbin, /usr/local/bin, etc.), and it gives you the $PATH environment variable to affect visibility. > What you're describing is a fundamentally painful thing to do. You > have to decide for every user what objects they should have access to > and which they shouldn't. Well, groups of users, yes. Roles. Pretty standard security stuff. > It doesn't get any ideasier if you have > every function hard coding inside it assumptions about what schemas it > will need. It's worth avoiding that, too. Or perhaps objects are aware of their own schemas, just as a subroutine in the Foo::Bar package in Perl can access another subroutine in the same package without having to put Foo::Bar:: in front of it. > How is this different from any other analogous system? The filesystem > uses directories for all three of the above, for example? Maybe it's not, but it could still be easier to use. > Having three different namespaces, one for organizing your code, one > to control visibility, and one to control security would be 9 times > more complex, i think. But people are doing this already. We should make their jobs easier. > 3rd-party vendor code is precisely what I'm thinking of when I point > out that having global state to override what the code requests is a > recipe for problems. 3rd-party vendors would be left with no way to > write their code such that they could guarantee it would work -- the > DBA would always be able to break it by setting this variable. And > some other code might require this variable to be set leaving the > hapless DBA with no right option. But not, perhaps, if objects automatically know about other objects in their own schemas. Put another way, when a function in the "foo" schema is called, it would transparently use the search path "foo, $search_path" whenever it tried to do anything. >> However, if we had push/pop/shift/unshift for search_path, the need >> for >> search_path_suffix would be considerably diminished, since >> application code >> (& DBAs) would use push/pop instead of replacing the entire >> search_path. > > Well I don't mind push but I still think pop is an error. What you > really want to do is restore it to the value you started with. You > don't want to remove the last element since that may not be the > element you added. Some function you called may have added an extra > element on the head. I think it's worth it to be complete in the implementation, and not leave things out because we think someone might shoot themselves in the foot. Best, David
pgsql-hackers by date: