begriffs open source - ai-pg/blob - full-docs/txt/ddl-depend.txt

   1
   2 5.15. Dependency Tracking #
   3
   4    When you create complex database structures involving many tables with
   5    foreign key constraints, views, triggers, functions, etc. you
   6    implicitly create a net of dependencies between the objects. For
   7    instance, a table with a foreign key constraint depends on the table it
   8    references.
   9
  10    To ensure the integrity of the entire database structure, PostgreSQL
  11    makes sure that you cannot drop objects that other objects still depend
  12    on. For example, attempting to drop the products table we considered in
  13    Section 5.5.5, with the orders table depending on it, would result in
  14    an error message like this:
  15 DROP TABLE products;
  16
  17 ERROR:  cannot drop table products because other objects depend on it
  18 DETAIL:  constraint orders_product_no_fkey on table orders depends on table prod
  19 ucts
  20 HINT:  Use DROP ... CASCADE to drop the dependent objects too.
  21
  22    The error message contains a useful hint: if you do not want to bother
  23    deleting all the dependent objects individually, you can run:
  24 DROP TABLE products CASCADE;
  25
  26    and all the dependent objects will be removed, as will any objects that
  27    depend on them, recursively. In this case, it doesn't remove the orders
  28    table, it only removes the foreign key constraint. It stops there
  29    because nothing depends on the foreign key constraint. (If you want to
  30    check what DROP ... CASCADE will do, run DROP without CASCADE and read
  31    the DETAIL output.)
  32
  33    Almost all DROP commands in PostgreSQL support specifying CASCADE. Of
  34    course, the nature of the possible dependencies varies with the type of
  35    the object. You can also write RESTRICT instead of CASCADE to get the
  36    default behavior, which is to prevent dropping objects that any other
  37    objects depend on.
  38
  39 Note
  40
  41    According to the SQL standard, specifying either RESTRICT or CASCADE is
  42    required in a DROP command. No database system actually enforces that
  43    rule, but whether the default behavior is RESTRICT or CASCADE varies
  44    across systems.
  45
  46    If a DROP command lists multiple objects, CASCADE is only required when
  47    there are dependencies outside the specified group. For example, when
  48    saying DROP TABLE tab1, tab2 the existence of a foreign key referencing
  49    tab1 from tab2 would not mean that CASCADE is needed to succeed.
  50
  51    For a user-defined function or procedure whose body is defined as a
  52    string literal, PostgreSQL tracks dependencies associated with the
  53    function's externally-visible properties, such as its argument and
  54    result types, but not dependencies that could only be known by
  55    examining the function body. As an example, consider this situation:
  56 CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
  57                              'green', 'blue', 'purple');
  58
  59 CREATE TABLE my_colors (color rainbow, note text);
  60
  61 CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
  62   'SELECT note FROM my_colors WHERE color = $1'
  63   LANGUAGE SQL;
  64
  65    (See Section 36.5 for an explanation of SQL-language functions.)
  66    PostgreSQL will be aware that the get_color_note function depends on
  67    the rainbow type: dropping the type would force dropping the function,
  68    because its argument type would no longer be defined. But PostgreSQL
  69    will not consider get_color_note to depend on the my_colors table, and
  70    so will not drop the function if the table is dropped. While there are
  71    disadvantages to this approach, there are also benefits. The function
  72    is still valid in some sense if the table is missing, though executing
  73    it would cause an error; creating a new table of the same name would
  74    allow the function to work again.
  75
  76    On the other hand, for an SQL-language function or procedure whose body
  77    is written in SQL-standard style, the body is parsed at function
  78    definition time and all dependencies recognized by the parser are
  79    stored. Thus, if we write the function above as
  80 CREATE FUNCTION get_color_note (rainbow) RETURNS text
  81 BEGIN ATOMIC
  82   SELECT note FROM my_colors WHERE color = $1;
  83 END;
  84
  85    then the function's dependency on the my_colors table will be known and
  86    enforced by DROP.