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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
