On 1/24/07, Merlin Moncure <mmoncure@gmail.com> wrote:
> when you create them. Table rights almost always follow broad rules
> so it only natural to integrate that with schemas somehow...but
> admittedly it is awkward to put it into GRANT (and I've thought alot a
> bout.

oops what I meant to say here is that I don't think it's possible
to this in the way that Stephen wants because it would hack up GRANT
to much. Tom was at least half right, this proposal was not discarded
out of hand but it was on pretty shaky ground...I was one of the big
supporters of extending grant this way in the original discussion but
I think it might be the wrong approach.

merlin

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

* Merlin Moncure (mmoncure@gmail.com) wrote:
> On 1/24/07, Merlin Moncure <mmoncure@gmail.com> wrote:
> >when you create them. Table rights almost always follow broad rules
> >so it only natural to integrate that with schemas somehow...but
> >admittedly it is awkward to put it into GRANT (and I've thought alot a
> >bout.
>
> oops what I meant to say here is that I don't think it's possible
> to this in the way that Stephen wants because it would hack up GRANT
> to much. Tom was at least half right, this proposal was not discarded
> out of hand but it was on pretty shaky ground...I was one of the big
> supporters of extending grant this way in the original discussion but
> I think it might be the wrong approach.

err, what proposal wasn't touching the GRANT syntax at all but rather
adding some options to ALTER SCHEMA which I didn't think was all that
bad (and wasn't commented on except to point out that I needed to handle
different object types seperately). The current opposition, aiui, is
against having a 'default owner' for new objects in a schema and not the
default ACLs per schema.

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

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFt4o1rzgMPqB3kigRAqNqAJ4tufcE5jROX5wQ/0fTbx16UrJxTACfVLsy
JNCQTGTdCPDzjZW0zZSeUsE=
=UJE8
-----END PGP SIGNATURE-----

On 1/24/07, Stephen Frost <sfrost@snowman.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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

* Merlin Moncure (mmoncure@gmail.com) wrote:
> On 1/24/07, Stephen Frost <sfrost@snowman.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

These are pretty different things actually, imv.. I don't think it
makes sense to use GRANT on something which is clearly a schema
property. Would you still track the information in pg_namespace?
Nothing else makes sense to me and if it's there I think it's perfectly
reasonable to modify a schema property using ALTER SCHEMA. Hacking up
GRANT to do it sounds very, very ugly and not intuitive...

> and your proposal would make alter schema (and presumably create
> schema) the only command(s) that deal with privileges excluding

The proposal didn't involve CREATE SCHEMA. I don't really have a strong
opinion on that but I'm at least disinclined towards it as being
unnecessary.

> 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.

It doesn't seem unsuprising at all to me, especially with appropriate
documentation... Having the syntax in GRANT or in ALTER SCHEMA would
work for me for the ACLs. I don't see how that distincation does
anything to solve the concerns or provide a solution for ownership
delegation. Especially considering you can't change ownership with
GRANT today...

> >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.

Ok. The issue that I have is that some permissions are exclusivly
available only to the owner of an object, and it's not possible to grant
them. I feel that it should be possible to have those permissions
applied to objects when they are created as well...

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFt69vrzgMPqB3kigRApYeAJoDC4UUGR257Qp4cIdjxL 8JxAHQRgCeN2rO
EBicGIZIufeeA6AOPvAdmCI=
=jXz0
-----END PGP SIGNATURE-----