Skip site navigation (1) Skip section navigation (2)

Re: search_path improvements

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Greg Stark <stark(at)enterprisedb(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: search_path improvements
Date: 2009-05-31 23:52:24
Message-ID: CC366B5F-F7BB-49E9-9292-CD70C56061D5@kineticode.com (view raw or flat)
Thread:
Lists: 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(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


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-06-01 00:05:31
Subject: Re: [GENERAL] INTERVAL data type and libpq - what format?
Previous:From: Greg StarkDate: 2009-05-31 22:47:16
Subject: Re: search_path improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group