From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncate Triggers |
Date: | 2008-01-26 21:00:12 |
Message-ID: | 20080126210012.GX5031@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > iirc, the suggestion was to exclude the non-SQL-spec things from 'GRANT
> > ALL' to avoid just that issue. Having to grant TRUNCATE and/or DDL
> > operation permissions explicitly would be reasonable. This might create
> > a disconnect with what 'revoke all' does, since that should really
> > remove all of the perms, but I feel that's reasonable. A 'Default
> > secure' approach.
>
> More like "default impossibly confusing" :-(. "GRANT ALL" doesn't mean
> grant all privileges? How the heck are you going to explain/justify
> that to a newbie?
"grant all" *already* doesn't mean grant all privileges. This isn't
really a change from that. Additionally, there's lots of places where
we follow the SQL spec because that's the right thing to do even though
it's not always the most intuitive thing to do. I certainly don't feel
this is 'impossibly confusing' any more than 'grant all' doesn't mean
you can truncate or alter the table today.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | tomas | 2008-01-27 05:31:29 | Re: Simple row serialization? |
Previous Message | Oleg Bartunov | 2008-01-26 19:42:58 | Re: Simple row serialization? |