外部キー制約や、ビュー、トリガ、関数などを使ったテーブルが多数含まれるような複雑なデータベース構造を作成すると、ユーザはそれらのオブジェクト間の暗黙的な依存関係のネットワークも作成していることになります。外部キー制約を持つテーブルは、参照するテーブルに依存しています。データベース構造全体の整合性を保つため、PostgreSQLは、他のオブジェクトと依存関係にあるオブジェクトの削除を許可しません。外部キーで検討したproductsテーブルを削除しようとしても、ordersテーブルがこのテーブルに依存しているので、以下のようなエラーメッセージが現れます。too.エラーメッセージには役に立つヒントが含まれています。以下のようにすると、依存する全てのオブジェクトを1つずつ削除する手間を省けます。CASCADE;これで、全ての依存オブジェクトが削除され、それらに依存するいかなるオブジェクトも削除されます。この場合、ordersテーブルは削除されずに外部キー制約のみが削除されます。外部キー制約に依存するものが何もないので、処理がそこで停止します。CASCADEが何を行うかを知りたい場合は、CASCADEを指定せずにDROPを実行してDETAIL出力を読んでください)。PostgreSQLでは、ほぼ全てのDROPコマンドにCASCADEを指定することができます。どのような依存関係が存在するかは、オブジェクトの種類によって異なります。CASCADEではなくRESTRICTと記述すると、他のオブジェクトが依存しているオブジェクトの削除を禁止するというデフォルトの振舞いを指定することもできます。標準SQLでは、DROPコマンドでRESTRICTまたはCASCADEのいずれかを指定する必要があります。実際にこの決まり通りのデータベースシステムはありませんが、デフォルトがRESTRICTであるか、CASCADEであるかは、システムによって異なります。DROPコマンドで複数のオブジェクトを羅列した場合、CASCADEは、指定されたグループの外部に依存関係が存在する時のみ要求されます。tab2と記述したとき、tab2からtab1への外部キー参照の存在は、CASCADEの指定がコマンド成功に必要とされるということを意味しません。ユーザ定義関数について、PostgreSQLは引数や結果の型など、関数の外部に可視な属性に関連した依存性については追跡しますが、関数の実体を検査することによってしかわからない依存性は追跡しません。以下の状況を考えてみます。問い合わせ言語(SQL)関数を参照してください。PostgreSQLは関数get_color_noteが型rainbowに依存することは認識します。その型を削除すると、関数の引数の型が定義されなくなるため、関数の削除も強制されます。PostgreSQLはget_color_noteがテーブルmy_colorsに依存するとは考えません。従って、そのテーブルが削除されても関数は削除されません。この方法には不利な点もありますが、同時に利益もあります。テーブルがない状態で関数を実行すればエラーを引き起こしますが、それでも関数はある意味で、有効な状態になっています。そのため、同じ名前の新しいテーブルを作成することで、関数を再び動作させることができます。