當您建立包含許多具有外部索引鍵約束、檢視、觸發器、函式等的表的複雜資料庫結構時，您會隱式地建立物件之間依賴關係的集合。例如，具有外部索引鍵約束的表依賴於它所引用的表。

為了確保整個資料庫結構的完整性，PostgreSQL 會確保您不能刪除其他物件仍然依賴的物件。例如，嘗試刪除我們在第 5.5.5 節中考慮過的 products 表，而 orders 表依賴於它，將會導致如下錯誤訊息：

DROP TABLE products;

ERROR:  cannot drop table products because other objects depend on it
DETAIL:  constraint orders_product_no_fkey on table orders depends on table products
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

錯誤訊息包含一個有用的提示：如果您不想逐個刪除所有依賴物件，您可以執行：

DROP TABLE products CASCADE;

這樣可以刪除所有依賴物件，以及依賴於它們的所有物件，進行遞迴刪除。在這種情況下，它不會刪除 orders 表，只刪除外部索引鍵約束。它在此停止，因為沒有物件依賴於外部索引鍵約束。（如果您想檢查 DROP ... CASCADE 會做什麼，請在不帶 CASCADE 的情況下執行 DROP 並閱讀 DETAIL 輸出。）

PostgreSQL 中幾乎所有的 DROP 命令都支援指定 CASCADE。當然，可能的依賴關係的性質隨物件的型別而變化。您也可以使用 RESTRICT 而不是 CASCADE 來獲得預設行為，即阻止刪除任何其他物件依賴的物件。

如果 DROP 命令列出了多個物件，則僅當存在指定組之外的依賴關係時才需要 CASCADE。例如，當說 DROP TABLE tab1, tab2 時，如果存在一個引用 tab1 並從 tab2 來的外部索引鍵，這並不意味著需要 CASCADE 才能成功。

對於主體定義為字串字面量的使用者定義函式或過程，PostgreSQL 會跟蹤與函式外部可見屬性（如其引數和結果型別）相關的依賴關係，但**不**會跟蹤只能透過檢查函式主體來識別的依賴關係。例如，考慮以下情況：

CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
                             'green', 'blue', 'purple');

CREATE TABLE my_colors (color rainbow, note text);

CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
  'SELECT note FROM my_colors WHERE color = $1'
  LANGUAGE SQL;

(有關 SQL 語言函式，請參閱第 36.5 節。) PostgreSQL 會知道 get_color_note 函式依賴於 rainbow 型別：刪除該型別將強制刪除該函式，因為其引數型別將不再被定義。但是 PostgreSQL 不會將 get_color_note 視為依賴於 my_colors 表，因此如果刪除該表，將不會刪除該函式。雖然這種方法有缺點，但也有優點。如果表丟失，該函式在某種意義上仍然是有效的，儘管執行它會導致錯誤；建立一個同名的新表將允許函式再次工作。

另一方面，對於主體是用 SQL 標準樣式編寫的 SQL 語言函式或過程，主體在函式定義時被解析，並且所有解析器識別的依賴關係都會被儲存。因此，如果我們這樣編寫上面的函式：

CREATE FUNCTION get_color_note (rainbow) RETURNS text
BEGIN ATOMIC
  SELECT note FROM my_colors WHERE color = $1;
END;

那麼函式對 my_colors 表的依賴關係將是已知的，並且會被 DROP 強制執行。