From afb10b3b298c1012908a7d0f491a6a852c64e38d Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 26 Oct 2016 11:46:26 -0400 Subject: [PATCH] Doc: improve documentation about inheritance. Clarify documentation about inheritance of check constraints, in particular mentioning the NO INHERIT option, which didn't exist when this text was written. Document that in an inherited query, the applicable row security policies are those of the explicitly-named table, not its children. This is the intended behavior (per off-list discussion with Stephen Frost), and there are regression tests for it, but it wasn't documented anywhere user-facing as far as I could find. Do a bit of wordsmithing on the description of inherited access-privilege checks. Back-patch to 9.5 where RLS was added. --- doc/src/sgml/ddl.sgml | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index e139f643f3..76af30fc05 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -2559,7 +2559,8 @@ VALUES ('Albany', NULL, NULL, 'NY'); All check constraints and not-null constraints on a parent table are - automatically inherited by its children. Other types of constraints + automatically inherited by its children, unless explicitly specified + otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited. @@ -2570,10 +2571,12 @@ VALUES ('Albany', NULL, NULL, 'NY'); same column name appears in multiple parent tables, or in both a parent table and the child's definition, then these columns are merged so that there is only one such column in the child table. To be merged, - columns must have the same data types, else an error is raised. The - merged column will have copies of all the check constraints coming from - any one of the column definitions it came from, and will be marked not-null - if any of them are. + columns must have the same data types, else an error is raised. + Inheritable check constraints and not-null constraints are merged in a + similar fashion. Thus, for example, a merged column will be marked + not-null if any one of the column definitions it came from is marked + not-null. Check constraints are merged if they have the same name, + and the merge will fail if their conditions are different. @@ -2625,12 +2628,19 @@ VALUES ('Albany', NULL, NULL, 'NY'); - 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. + Inherited queries perform access permission checks on the parent table + only. Thus, for example, granting UPDATE permission on + the cities table implies permission to update rows in + the capitals table as well, when they are + accessed through cities. This preserves the appearance + that the data is (also) in the parent table. But + the capitals table could not be updated directly + without an additional grant. In a similar way, the parent table's row + security policies (see ) are applied to + rows coming from child tables during an inherited query. A child table's + policies, if any, are applied only when it is the table explicitly named + in the query; and in that case, any policies attached to its parent(s) are + ignored.