mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Some additional information about when to use referential actions

Browse Source
This commit is contained in:
Peter Eisentraut 2021-12-01 11:25:58 +01:00
parent 41e66fee05
commit 5786fe154b
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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