PostgreSQL：列表相關的行

如何查看哪些條目依賴於使用PostgreSQL的給定條目？（依賴意思是「有一個外鍵參考條目」）。PostgreSQL：列表相關的行

基本上，我想檢查哪些條目可能級聯，當我DELETE給定條目的表。

來源

2012-10-05 Weier

'SELECT * FROM dependent_table WHERE reference_key = @ given_reference_key'？或者你不知道dependent_table名稱/可能有多個依賴表？ –

http://www.postgresql.org/docs/7.3/static/ddl-depend.html –

@NoxHarmonium：請不要鏈接到完全過時的手冊。 –

要根據fk約束查看所有實際的行，請使用下述工具標識列。

如果使用ON DELETE CASCADE定義外鍵約束，則將刪除行（可能會將DELETE級聯到更多，具體取決於表）。

如果使用ON DELETE SET NULL/ON DELETE SET DEFAULT定義外鍵約束，則只有列中的值將重置爲NULL /默認值。

否則具有相關行的行上的DELETE將失敗併產生異常。

然後運行像識別的表/列以下查詢：

SELECT f.tbl_fk_id, f.col_fk 
FROM tbl_fk f 
JOIN tbl t ON f.col_fk = t.col 
AND <same condition as DELETE here>;

pgAdmin提供此功能：

Dependents

選擇的對象在對象瀏覽器左邊並選擇了依賴窗格右上角。

pgAdmin對系統目錄使用一些查詢來組裝列表。如果您想自己構建查詢，則可以記錄發出的命令。

此外，在刪除不完全確定依賴項的對象時，請首先嚐試使用普通的DROP（不含CASCADE）。如果有任何依賴項存在，您將收到錯誤消息...

最後，但請謹慎操作！，你可以start a transaction，只是發出命令：

BEGIN; 
DROP TABLE tbl CASCADE;

然後，如果你喜歡你所看到的：

COMMIT;

如果不這樣做：

ROLLBACK;

，它會就像它從未發生過。;）

你會看到這樣的事情：

NOTICE: drop cascades to 4 other objects 
DETAIL: drop cascades to constraint tbl1_tbl_id_fkey on table myschema.tbl1 
drop cascades to constraint tbl_winner_tbl_id_fkey on table myschema.tbl_foo 
drop cascades to constraint bar_tbl_id_fkey on table myschema.bar 
drop cascades to constraint tbl1_tbl_id_fkey on table x.tbl1 

Query returned successfully with no result in 47 ms.

來源

2012-10-05 15:29:19

我想他想看到將被刪除的**行**，而不是依賴表。 –

@a_horse_with_no_name：啊，重新閱讀這個問題，你可能是對的，謝謝。我添加了一個段落來實際行。 –

我希望有一種方法可以在不實際使用DELETE命令的情況下獲取信息「drop cascades ...」（NOTICE），但BEGIN/ROLLBACK是個好主意。 – Weier

您可以從PostgreSQL系統目錄直接查詢這樣的：

SELECT 
    depending.relname as depending_table, 
    referenced.relname as referenced_table 
FROM pg_catalog.pg_depend d 
JOIN pg_catalog.pg_constraint fkey ON fkey.oid=d.objid AND fkey.contype='f' 
JOIN pg_catalog.pg_class depending ON depending.oid=fkey.conrelid 
JOIN pg_catalog.pg_class referenced ON referenced.oid=d.refobjid 
WHERE fkey.confdeltype='c'    -- just cascading deletes 
    AND referenced.oid != depending.oid -- ignoring reflexive dependencies 
    AND referenced.relkind='r'   -- tables only

見this SQL Fiddle和相關文件：

pg_depend瞭解依賴關係
pg_constraint用於瞭解外鍵
pg_class學習有關表

擴展這一來告訴你參與就留給讀者自己練習的列。（提示：pg_attribute。）

來源

2012-10-05 15:56:31 willglynn

請注意，系統目錄不能保證在主要版本之間兼容，並且在過去以不兼容的方式反覆更改。如果儘可能使用'information_schema'來代替。 –

這個查詢按照原樣針對早於8.0的PostgreSQL，並且只需要一個小的更改就可以使用7.x（檢查以確定是否刪除級聯）。你說的沒有標準，但是'pg_catalog'確實不會經常改變。（這也有可能是我養成了查詢標準視圖中不存在的信息的習慣......） – willglynn

查詢並不完全符合我的要求（行列表，而不是表格），但仍然有助於檢查依賴關係。 – Weier

現有答案使用pg_catalog，這是可以的，但可以在主要版本的PostgreSQL之間不相容地改變。只要有可能，您應該使用the information_schema。

SELECT * 
FROM information_schema.constraint_column_usage ccu 
INNER JOIN information_schema.referential_constraints rc 
USING (constraint_catalog, constraint_schema, constraint_name);

參見：

來源

2012-10-06 01:46:36

我在這裏實際上並沒有使用'pg_catalog' - 但是如果我詳細介紹的話，我可能會遇到。 'information_schema'對象通常比查詢慢得多。它們只是（有時是非常複雜的）基礎'pg_catalog'對象的視圖，通常會涉及許多與您的查詢無關的表。'information_schema'是標準化的，並且應該在主要版本之間保持穩定，即使是跨數據庫（實現它）。所以它當然有它的用途。但Postgres團隊也不會輕易更改'pg_catalog'表格。對於即席查詢，我總是使用'pg_catalog'。 –

@ErwinBrandstetter好點。我假設可能是錯誤的，意圖是將查詢嵌入到應用程序或工具中。如果是臨時的，那麼pg_catalog肯定是要走的路（通常更容易查詢）。 –

爲了說明比較你的（看似簡單）查詢與@ willglynn的（看似複雜的）查詢與'EXPLAIN ANALYZE' .. –

PostgreSQL：列表相關的行

回答

相關問題