opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity

docs: replace 'master' with 'root' where appropriate. 

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.x7lch5n6kcjq4aue@alap3.anarazel.de
This commit is contained in:
Andres Freund 2020-06-15 10:18:41 -07:00
parent 9e101cf606
commit 09dfd43011
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/src/sgml/ddl.sgml
View File

@ -4142,12 +4142,12 @@ ALTER INDEX measurement_city_id_logdate_key
<orderedlist spacing="compact">
<listitem>
<para>
Create the <quote>master</quote> table, from which all of the
Create the <quote>root</quote> table, from which all of the
<quote>child</quote> 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 <structname>measurement</structname>
example, the root table is the <structname>measurement</structname>
table as originally defined.
</para>
</listitem>
@ -4155,8 +4155,8 @@ ALTER INDEX measurement_city_id_logdate_key
<listitem>
<para>
Create several <quote>child</quote> 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
<productname>PostgreSQL</productname> tables (or foreign tables).
</para>
@ -4244,7 +4244,7 @@ CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);
We want our application to be able to say <literal>INSERT INTO
measurement ...</literal> 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;
<para>
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:
<programlisting>
CREATE RULE measurement_insert_y2006m02 AS
@ -4351,7 +4351,7 @@ DO INSTEAD
<para>
Be aware that <command>COPY</command> ignores rules. If you want to
use <command>COPY</command> to insert data, you'll need to copy into the
correct child table rather than directly into the master. <command>COPY</command>
correct child table rather than directly into the root. <command>COPY</command>
does fire triggers, so you can use it normally if you use the trigger
approach.
</para>
@ -4359,7 +4359,7 @@ DO INSTEAD
<para>
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.
</para>
</listitem>
@ -4473,7 +4473,7 @@ ALTER TABLE measurement_y2008m02 INHERIT measurement;
<programlisting>
ANALYZE measurement;
</programlisting>
will only process the master table.
will only process the root table.
</para>
</listitem>