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:
parent
9e101cf606
commit
09dfd43011
|
@ -4142,12 +4142,12 @@ ALTER INDEX measurement_city_id_logdate_key
|
||||||
<orderedlist spacing="compact">
|
<orderedlist spacing="compact">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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
|
<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
|
define any check constraints on this table, unless you intend them
|
||||||
to be applied equally to all child tables. There is no point in
|
to be applied equally to all child tables. There is no point in
|
||||||
defining any indexes or unique constraints on it, either. For our
|
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.
|
table as originally defined.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
@ -4155,8 +4155,8 @@ ALTER INDEX measurement_city_id_logdate_key
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Create several <quote>child</quote> tables that each inherit from
|
Create several <quote>child</quote> tables that each inherit from
|
||||||
the master table. Normally, these tables will not add any columns
|
the root table. Normally, these tables will not add any columns
|
||||||
to the set inherited from the master. Just as with declarative
|
to the set inherited from the root. Just as with declarative
|
||||||
partitioning, these tables are in every way normal
|
partitioning, these tables are in every way normal
|
||||||
<productname>PostgreSQL</productname> tables (or foreign tables).
|
<productname>PostgreSQL</productname> tables (or foreign tables).
|
||||||
</para>
|
</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
|
We want our application to be able to say <literal>INSERT INTO
|
||||||
measurement ...</literal> and have the data be redirected into the
|
measurement ...</literal> and have the data be redirected into the
|
||||||
appropriate child table. We can arrange that by attaching
|
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
|
If data will be added only to the latest child, we can
|
||||||
use a very simple trigger function:
|
use a very simple trigger function:
|
||||||
|
|
||||||
|
@ -4326,7 +4326,7 @@ LANGUAGE plpgsql;
|
||||||
<para>
|
<para>
|
||||||
A different approach to redirecting inserts into the appropriate
|
A different approach to redirecting inserts into the appropriate
|
||||||
child table is to set up rules, instead of a trigger, on the
|
child table is to set up rules, instead of a trigger, on the
|
||||||
master table. For example:
|
root table. For example:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE RULE measurement_insert_y2006m02 AS
|
CREATE RULE measurement_insert_y2006m02 AS
|
||||||
|
@ -4351,7 +4351,7 @@ DO INSTEAD
|
||||||
<para>
|
<para>
|
||||||
Be aware that <command>COPY</command> ignores rules. If you want to
|
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
|
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
|
does fire triggers, so you can use it normally if you use the trigger
|
||||||
approach.
|
approach.
|
||||||
</para>
|
</para>
|
||||||
|
@ -4359,7 +4359,7 @@ DO INSTEAD
|
||||||
<para>
|
<para>
|
||||||
Another disadvantage of the rule approach is that there is no simple
|
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
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
@ -4473,7 +4473,7 @@ ALTER TABLE measurement_y2008m02 INHERIT measurement;
|
||||||
<programlisting>
|
<programlisting>
|
||||||
ANALYZE measurement;
|
ANALYZE measurement;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
will only process the master table.
|
will only process the root table.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue