On May 31, 2009, at 3:47 PM, Greg Stark wrote:
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
