On Sun, Sep 9, 2012 at 07:06:07PM +0200, Kohei KaiGai wrote: > I noticed a sentence in sepgsql says 180-degree opposite at: > > When <literal>DROP</> command is executed, <literal>drop</> will be > checked on the object being removed for each object types. Permissions > "will not be" checked for objects dropped indirectly via > <literal>CASCADE</>. > > This should be "will also be", as our implementation doing. > I'm not sure why I described such a wrong stuff. Anyway, the attached > patch will fix it.
Patch attached to git head and 9.2. Sorry for the delay. --------------------------------------------------------------------------- > > Thanks, > -- > KaiGai Kohei <kai...@kaigai.gr.jp> > doc/src/sgml/sepgsql.sgml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml > index ff083a0..27bc2e6 100644 > --- a/doc/src/sgml/sepgsql.sgml > +++ b/doc/src/sgml/sepgsql.sgml > @@ -443,7 +443,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; > <para> > When <literal>DROP</> command is executed, <literal>drop</> will be > checked on the object being removed for each object types. Permissions > - will not be checked for objects dropped indirectly via > <literal>CASCADE</>. > + will be also checked for objects dropped indirectly via > <literal>CASCADE</>. > Deletion of objects contained within a particular schema (tables, views, > sequences and procedures) additionally requires > <literal>remove_name</> on the schema. > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers