docs: replace 'master' with 'root' where appropriate.
authorAndres Freund
Mon, 15 Jun 2020 17:18:41 +0000 (10:18 -0700)
committerAndres Freund
Wed, 8 Jul 2020 20:08:34 +0000 (13:08 -0700)
These uses of 'master' refer to partitioning / inheritance. 'root'
seems more descriptive than 'master'.

Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/20200615182235[email protected]

doc/src/sgml/ddl.sgml

index 991323d3471035de6250fbb95054de8bb9dbedc1..f45c951b2b085345ec53bdf4f12a3ccfdeacc203 100644 (file)
@@ -4142,12 +4142,12 @@ ALTER INDEX measurement_city_id_logdate_key
       
        
         
-         Create the master table, from which all of the
+         Create the root table, from which all of the
          child tables will inherit.  This table will contain no data.  Do not
          define any check constraints on this table, unless you intend them
          to be applied equally to all child tables.  There is no point in
          defining any indexes or unique constraints on it, either.  For our
-         example, the master table is the measurement
+         example, the root table is the measurement
          table as originally defined.
         
        
@@ -4155,8 +4155,8 @@ ALTER INDEX measurement_city_id_logdate_key
        
         
          Create several child tables that each inherit from
-         the master table.  Normally, these tables will not add any columns
-         to the set inherited from the master.  Just as with declarative
+         the root table.  Normally, these tables will not add any columns
+         to the set inherited from the root.  Just as with declarative
          partitioning, these tables are in every way normal
          PostgreSQL tables (or foreign tables).
         
@@ -4244,7 +4244,7 @@ CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);
          We want our application to be able to say INSERT INTO
          measurement ... and have the data be redirected into the
          appropriate child table.  We can arrange that by attaching
-         a suitable trigger function to the master table.
+         a suitable trigger function to the root table.
          If data will be added only to the latest child, we can
          use a very simple trigger function:
 
@@ -4326,7 +4326,7 @@ LANGUAGE plpgsql;
         
          A different approach to redirecting inserts into the appropriate
          child table is to set up rules, instead of a trigger, on the
-         master table.  For example:
+         root table.  For example:
 
 
 CREATE RULE measurement_insert_y2006m02 AS
@@ -4351,7 +4351,7 @@ DO INSTEAD
         
          Be aware that COPY ignores rules.  If you want to
          use COPY to insert data, you'll need to copy into the
-         correct child table rather than directly into the masterCOPY
+         correct child table rather than directly into the rootCOPY
          does fire triggers, so you can use it normally if you use the trigger
          approach.
         
@@ -4359,7 +4359,7 @@ DO INSTEAD
         
          Another disadvantage of the rule approach is that there is no simple
          way to force an error if the set of rules doesn't cover the insertion
-         date; the data will silently go into the master table instead.
+         date; the data will silently go into the root table instead.
         
        
 
@@ -4473,7 +4473,7 @@ ALTER TABLE measurement_y2008m02 INHERIT measurement;
 
 ANALYZE measurement;
 
-        will only process the master table.
+        will only process the root table.