Re: Schema (namespace) privilege details

Tom Lane wrote:
>>This looks good to me. I only wonder if public should default to world 
>>read and no create?
> 
> 
> That would be non-backwards-compatible.  Since the main reason for
> having the public namespace at all is backwards compatibility of the
> out-of-the-box behavior, I think we have to let it default to world
> write.  DBAs can revoke world write, or even remove the public namespace
> altogether, if they want to run a tighter ship.

Ah yes, I forgot about that aspect.

> 
> Also, if a database owner is not superuser, I do not think he should be
> able to create objects that are marked as belonging to other users.
> At least not in general.  Do we need to make an exception for schemas?
> 

Well, I like to think of the database owner as the superuser within that 
one database. This is similar to (at least) SQL Server and Oracle. But I 
don't think either of those systems have quite this issue because the 
notion of schema and login user are so tightly coupled, something you 
were specifically trying to avoid ;-)



> 
>>Agreed. How would it work though if say I wanted to create a view in the 
>>public schema, which pointed at a table in a schema which has had SELECT 
>>revoked? Same question for a public function/private table. It would be 
>>ideal if you could do this.
> 
> 
> AFAICS this would not be checked at creation time, but when someone
> tries to use the view; just the same as now.

Great!

Thanks,

Joe