On May 31, 2009, at 3:47 PM, Greg Stark wrote:
> On Sun, May 31, 2009 at 9:12 PM, Josh Berkus <josh(at)agliodbs(dot)com>
>> 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
> 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
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
>> search_path_suffix would be considerably diminished, since
>> application code
>> (& DBAs) would use push/pop instead of replacing the entire
> 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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-06-01 00:05:31|
|Subject: Re: [GENERAL] INTERVAL data type and libpq - what format? |
|Previous:||From: Greg Stark||Date: 2009-05-31 22:47:16|
|Subject: Re: search_path improvements|