a sentence in sepgsql.sgml says 180-degree opposite

Started by Kohei KaiGaiover 13 years ago2 messages

kaigai@kaigai.gr.jp

over 13 years ago

1 attachment(s)

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.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Attachments:

pgsql-v9.2-sepgsql-document-fixup.patchapplication/octet-stream; name=pgsql-v9.2-sepgsql-document-fixup.patchDownload

 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.

Bruce Momjian

bruce@momjian.us

almost 13 years ago

In reply to: Kohei KaiGai (#1)

Re: a sentence in sepgsql.sgml says 180-degree opposite

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers