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
