Re: Default permissisons from schemas

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Stephen Frost" <sfrost(at)snowman(dot)net>, "Jim Nasby" <decibel(at)decibel(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default permissisons from schemas
Date: 2007-01-24 18:30:03
Message-ID: b42b73150701241030g5706ce2bndd8deb758e6f4ba7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/24/07, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> err, what proposal wasn't touching the GRANT syntax at all but rather

right, but the original proposal did:
# %Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command

which was more or less (with the NEW TABLES flavor of the command)
duplicated by:

# Allow GRANT/REVOKE permissions to be inherited by objects based on
schema permissions

and your proposal would make alter schema (and presumably create
schema) the only command(s) that deal with privileges excluding
grant/revoke. That, IMO is actually a bad thing...a surprising
behavior. I think the 'new tables' form is better but has the same
problems as your proposal in that it does not disambiguate sequences
from tables, etc. It would however solve (I think!) your problem
without resorting to ownership delegation.

>I don't think it makes sense to have this syntax be part of the GRANT
syntax since it's really about a schema..

So, basically I disagree with the above, and agree with the others wrt
ownership change, but very much agree if it is pratical that having
some mechanism of applying permissions to objects when they are
created depending on which schema they are in is a good thing.

merlin

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-01-24 18:35:44 Re: weird buildfarm failures on arm/mipsel and --with-tcl
Previous Message Peter Eisentraut 2007-01-24 18:15:21 Re: tsearch in core patch, for inclusion