當您建立複雜的資料庫結構，其中包含許多具有外部鍵約束、檢視表、觸發器、函數等的表格時，您會隱式地在物件之間建立一個相依性的網路。 例如，具有外部鍵約束的表格相依於它所參考的表格。

為了確保整個資料庫結構的完整性，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 時，從 tab2 參考 tab1 的外部鍵的存在並不表示需要 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;

那麼 DROP 將會知道並強制執行該函數對 my_colors 表格的相依性。