When querying a table with child tables, do not check permissions on the

child tables.  This was found to be useless and confusing in virtually all
cases, and also contrary to the SQL standard.

Author: petere

doc/src/sgml/ddl.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.87 2009/06/17 21:58:49 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.88 2009/10/23 05:24:52 petere Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -2124,20 +2124,20 @@ VALUES ('New York', NULL, NULL, 'NY');
    and rejection that apply during <command>CREATE TABLE</command>.
   </para>
 
- <sect2 id="ddl-inherit-caveats">
-  <title>Caveats</title>
-
   <para>
-   Table access permissions are not automatically inherited.  Therefore,
-   a user attempting to access a parent table must either have permissions
-   to do the same operation on all its child tables as well, or must use the
-   <literal>ONLY</literal> notation.  When adding a new child table to
-   an existing inheritance hierarchy, be careful to grant all the needed
-   permissions on it.
+   Note how table access permissions are handled.  Querying a parent
+   table can automatically access data in child tables without further
+   access privilege checking.  This preserves the appearance that the
+   data is (also) in the parent table.  Accessing the child tables
+   directly is, however, not automatically allowed and would require
+   further privileges to be granted.
   </para>
 
+ <sect2 id="ddl-inherit-caveats">
+  <title>Caveats</title>
+
   <para>
-   More generally, note that not all SQL commands are able to work on
+   Note that not all SQL commands are able to work on
    inheritance hierarchies.  Commands that are used for data querying,
    data modification, or schema modification
    (e.g., <literal>SELECT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,

src/backend/optimizer/prep/prepunion.c

@@ -22,7 +22,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.176 2009/10/12 18:10:48 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.177 2009/10/23 05:24:52 petere Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1244,6 +1244,7 @@ expand_inherited_rtentry(PlannerInfo *root, RangeTblEntry *rte, Index rti)
 		childrte = copyObject(rte);
 		childrte->relid = childOID;
 		childrte->inh = false;
+		childrte->requiredPerms = 0; /* do not require permissions on child tables */
 		parse->rtable = lappend(parse->rtable, childrte);
 		childRTindex = list_length(parse->rtable);
 

src/test/regress/expected/privileges.out

@@ -406,11 +406,22 @@ SELECT fx FROM atestp2; -- ok
 ----
 (0 rows)
 
-SELECT fy FROM atestp2; -- fail, no privilege on atestc.fy
-ERROR:  permission denied for relation atestc
-SELECT atestp2 FROM atestp2; -- fail, no privilege on atestc.fy
-ERROR:  permission denied for relation atestc
-SELECT oid FROM atestp2; -- fail, no privilege on atestc.oid
+SELECT fy FROM atestp2; -- ok
+ fy 
+----
+(0 rows)
+
+SELECT atestp2 FROM atestp2; -- ok
+ atestp2 
+---------
+(0 rows)
+
+SELECT oid FROM atestp2; -- ok
+ oid 
+-----
+(0 rows)
+
+SELECT fy FROM atestc; -- fail
 ERROR:  permission denied for relation atestc
 SET SESSION AUTHORIZATION regressuser1;
 GRANT SELECT(fy,oid) ON atestc TO regressuser2;

src/test/regress/sql/privileges.sql

@@ -277,9 +277,10 @@ GRANT SELECT(fx) ON atestc TO regressuser2;
 
 SET SESSION AUTHORIZATION regressuser2;
 SELECT fx FROM atestp2; -- ok
-SELECT fy FROM atestp2; -- fail, no privilege on atestc.fy
-SELECT atestp2 FROM atestp2; -- fail, no privilege on atestc.fy
-SELECT oid FROM atestp2; -- fail, no privilege on atestc.oid
+SELECT fy FROM atestp2; -- ok
+SELECT atestp2 FROM atestp2; -- ok
+SELECT oid FROM atestp2; -- ok
+SELECT fy FROM atestc; -- fail
 
 SET SESSION AUTHORIZATION regressuser1;
 GRANT SELECT(fy,oid) ON atestc TO regressuser2;