On Tue, 27 May 2008, Tom Lane <[EMAIL PROTECTED]> writes:
> Well, you tested wrong then. It works as expected for me, which is
> that you need SELECT if the query involves fetching any existing
> column value:
Pff... Sorry for the noise. (I created example table under a differrent
schema than "public" to be able to test effects of schema priviliges to
INSERT/UPDATE/DELETE commands, but I somehow forgot that detail later.)
I updated the doc patch.
Regards.
Index: doc/src/sgml/ref/grant.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v
retrieving revision 1.68
diff -u -r1.68 grant.sgml
--- doc/src/sgml/ref/grant.sgml 5 May 2008 01:21:03 -0000 1.68
+++ doc/src/sgml/ref/grant.sgml 27 May 2008 18:01:56 -0000
@@ -461,6 +461,14 @@
access privileges display. A <literal>*</> will appear only when
grant options have been explicitly granted to someone.
</para>
+
+ <para>
+ It must also be noted that <term>UPDATE</term> and <term>DELETE</term>
+ queries involving <term>WHERE</term> clauses require <term>SELECT</term>
+ privilege to be able to scan related table to locate about to be updated
+ rows on the table. Usage of such queries without an appropriate
+ <term>SELECT</term> privilege will raise a permission error.
+ </para>
</refsect1>
<refsect1 id="sql-grant-examples">
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
