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 <kaigai@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
