diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/catalogs.sgml | 100 |
1 files changed, 70 insertions, 30 deletions
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 6dd0700da75..0fd792ff1a2 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2970,7 +2970,7 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l referenced object, and should be automatically dropped (regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal> mode) if the referenced object is dropped. Example: a named - constraint on a table is made autodependent on the table, so + constraint on a table is made auto-dependent on the table, so that it will go away if the table is dropped. </para> </listitem> @@ -2982,38 +2982,61 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <para> The dependent object was created as part of creation of the referenced object, and is really just a part of its internal - implementation. A <command>DROP</command> of the dependent object - will be disallowed outright (we'll tell the user to issue a - <command>DROP</command> against the referenced object, instead). A - <command>DROP</command> of the referenced object will be propagated - through to drop the dependent object whether - <command>CASCADE</command> is specified or not. Example: a trigger - that's created to enforce a foreign-key constraint is made - internally dependent on the constraint's - <structname>pg_constraint</structname> entry. + implementation. A direct <command>DROP</command> of the dependent + object will be disallowed outright (we'll tell the user to issue + a <command>DROP</command> against the referenced object, instead). + A <command>DROP</command> of the referenced object will result in + automatically dropping the dependent object + whether <literal>CASCADE</literal> is specified or not. If the + dependent object is reached due to a dependency on some other object, + the drop is converted to a drop of the referenced object, so + that <literal>NORMAL</literal> and <literal>AUTO</literal> + dependencies of the dependent object behave much like they were + dependencies of the referenced object. + Example: a view's <literal>ON SELECT</literal> rule is made + internally dependent on the view, preventing it from being dropped + while the view remains. Dependencies of the rule (such as tables it + refers to) act as if they were dependencies of the view. </para> </listitem> </varlistentry> <varlistentry> - <term><symbol>DEPENDENCY_INTERNAL_AUTO</symbol> (<literal>I</literal>)</term> + <term><symbol>DEPENDENCY_PARTITION_PRI</symbol> (<literal>P</literal>)</term> + <term><symbol>DEPENDENCY_PARTITION_SEC</symbol> (<literal>S</literal>)</term> <listitem> <para> The dependent object was created as part of creation of the referenced object, and is really just a part of its internal - implementation. A <command>DROP</command> of the dependent object - will be disallowed outright (we'll tell the user to issue a - <command>DROP</command> against the referenced object, instead). - While a regular internal dependency will prevent - the dependent object from being dropped while any such dependencies - remain, <literal>DEPENDENCY_INTERNAL_AUTO</literal> will allow such - a drop as long as the object can be found by following any of such + implementation; however, unlike <literal>INTERNAL</literal>, + there is more than one such referenced object. The dependent object + must not be dropped unless at least one of these referenced objects + is dropped; if any one is, the dependent object should be dropped + whether or not <literal>CASCADE</literal> is specified. Also + unlike <literal>INTERNAL</literal>, a drop of some other object + that the dependent object depends on does not result in automatic + deletion of any partition-referenced object. Hence, if the drop + does not cascade to at least one of these objects via some other + path, it will be refused. (In most cases, the dependent object + shares all its non-partition dependencies with at least one + partition-referenced object, so that this restriction does not + result in blocking any cascaded delete.) + Primary and secondary partition dependencies behave identically + except that the primary dependency is preferred for use in error + messages; hence, a partition-dependent object should have one + primary partition dependency and one or more secondary partition dependencies. - Example: an index on a partition is made internal-auto-dependent on - both the partition itself as well as on the index on the parent - partitioned table; so the partition index is dropped together with - either the partition it indexes, or with the parent index it is - attached to. + Note that partition dependencies are made in addition to, not + instead of, any dependencies the object would normally have. This + simplifies <command>ATTACH/DETACH PARTITION</command> operations: + the partition dependencies need only be added or removed. + Example: a child partitioned index is made partition-dependent + on both the partition table it is on and the parent partitioned + index, so that it goes away if either of those is dropped, but + not otherwise. The dependency on the parent index is primary, + so that if the user tries to drop the child partitioned index, + the error message will suggest dropping the parent index instead + (not the table). </para> </listitem> </varlistentry> @@ -3026,9 +3049,10 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l the referenced object (see <link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>). The dependent object can be dropped only via - <command>DROP EXTENSION</command> on the referenced object. Functionally - this dependency type acts the same as an internal dependency, but - it's kept separate for clarity and to simplify <application>pg_dump</application>. + <command>DROP EXTENSION</command> on the referenced object. + Functionally this dependency type acts the same as + an <literal>INTERNAL</literal> dependency, but it's kept separate for + clarity and to simplify <application>pg_dump</application>. </para> </listitem> </varlistentry> @@ -3038,10 +3062,13 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l <listitem> <para> The dependent object is not a member of the extension that is the - referenced object (and so should not be ignored by pg_dump), but - cannot function without it and should be dropped when the - extension itself is. The dependent object may be dropped on its - own as well. + referenced object (and so it should not be ignored + by <application>pg_dump</application>), but it cannot function + without the extension and should be auto-dropped if the extension is. + The dependent object may be dropped on its own as well. + Functionally this dependency type acts the same as + an <literal>AUTO</literal> dependency, but it's kept separate for + clarity and to simplify <application>pg_dump</application>. </para> </listitem> </varlistentry> @@ -3063,6 +3090,19 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l Other dependency flavors might be needed in future. </para> + <para> + Note that it's quite possible for two objects to be linked by more than + one <structname>pg_depend</structname> entry. For example, a child + partitioned index would have both a partition-type dependency on its + associated partition table, and an auto dependency on each column of + that table that it indexes. This sort of situation expresses the union + of multiple dependency semantics. A dependent object can be dropped + without <literal>CASCADE</literal> if any of its dependencies satisfies + its condition for automatic dropping. Conversely, all the + dependencies' restrictions about which objects must be dropped together + must be satisfied. + </para> + </sect1> |