Re: Schema (namespace) privilege details

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Schema (namespace) privilege details
Date: 2002-04-19 04:49:44
Message-ID: 3CBFA1E8.8090608@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2002-04-19 05:00:52 Re: Odd(?) RI-trigger behavior
Previous Message Stephan Szabo 2002-04-19 03:43:54 Re: Odd(?) RI-trigger behavior