postgres.git / summary / log / commit / refs
commit 5786fe154b53caef8b226ed863312d3608b32a51
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Wed Dec 01 10:25:58 2021 +0000
First released in: 15.0
doc: Some additional information about when to use referential actions
doc/src/sgml/ddl.sgml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 94f745aed03..642ea2a70d0 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1062,6 +1062,27 @@ CREATE TABLE order_items (
operation will fail.
</para>
+ <para>
+ The appropriate choice of <literal>ON DELETE</literal> action depends on
+ what kinds of objects the related tables represent. When the referencing
+ table represents something that is a component of what is represented by
+ the referenced table and cannot exist independently, then
+ <literal>CASCADE</literal> could be appropriate. If the two tables
+ represent independent objects, then <literal>RESTRICT</literal> or
+ <literal>NO ACTION</literal> is more appropriate; an application that
+ actually wants to delete both objects would then have to be explicit about
+ this and run two delete options. In the above example, order items are
+ part of an order, and it is convenient if they are deleted automatically
+ if an order is deleted. But products and orders are different things, and
+ so making a deletion of a product automatically cause the deletion of some
+ order items could be considered problematic. The actions <literal>SET
+ NULL</literal> or <literal>SET DEFAULT</literal> can be appropriate if a
+ foreign-key relationship represents optional information. For example, if
+ the products table contained a reference to a product manager, and the
+ product manager entry gets deleted, then setting the product's product
+ manager to null or a default might be useful.
+ </para>
+
<para>
Analogous to <literal>ON DELETE</literal> there is also
<literal>ON UPDATE</literal> which is invoked when a referenced
[parent: 41e66fee0516]