Re: search_path improvements

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>
> 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