Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped
От | Peter Geoghegan |
---|---|
Тема | Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped |
Дата | |
Msg-id | CAH2-WzkNQPEh-NV6T8AVqTcXNy1Y_4+PzS_n7xFmKpP+oDEj3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reported number of objects dropped
|
Список | pgsql-hackers |
On Thu, May 3, 2018 at 7:26 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > I bet this is related to how are these objects reached while walking the > dependency graph -- i.e. they are reached first as columns and reported > explicitly in the second case, but in the first case the tables are > reached first so the columns are not considered individually. So it'd > just be because of pg_depend scan order. There are a couple of other odd things that look related, such as this extract from the triggers.out section of my regression.diffs: *************** *** 1047,1056 **** NOTICE: main_view INSTEAD OF UPDATE ROW (instead_of_upd) NOTICE: OLD: (20,30), NEW: (20,31) NOTICE: trigger_func(before_upd_a_stmt) called: action = UPDATE, when = BEFORE, level = STATEMENT - NOTICE: trigger_func(after_upd_a_b_row) called: action = UPDATE, when = AFTER, level = ROW NOTICE: trigger_func(after_upd_b_row) called: action = UPDATE, when = AFTER, level = ROW ! NOTICE: trigger_func(after_upd_b_stmt) called: action = UPDATE, when = AFTER, level = STATEMENT NOTICE: trigger_func(after_upd_stmt) called: action = UPDATE, when = AFTER, level = STATEMENT NOTICE: main_view AFTER UPDATE STATEMENT (after_view_upd_stmt) UPDATE 1 UPDATE main_view SET b = 32 WHERE a = 21 AND b = 31 RETURNING a, b; --- 1051,1060 ---- NOTICE: main_view INSTEAD OF UPDATE ROW (instead_of_upd) NOTICE: OLD: (20,30), NEW: (20,31) NOTICE: trigger_func(before_upd_a_stmt) called: action = UPDATE, when = BEFORE, level = STATEMENT NOTICE: trigger_func(after_upd_b_row) called: action = UPDATE, when = AFTER, level = ROW ! NOTICE: trigger_func(after_upd_a_b_row) called: action = UPDATE, when = AFTER, level = ROW NOTICE: trigger_func(after_upd_stmt) called: action = UPDATE, when = AFTER, level = STATEMENT + NOTICE: trigger_func(after_upd_b_stmt) called: action = UPDATE, when = AFTER, level = STATEMENT NOTICE: main_view AFTER UPDATE STATEMENT (after_view_upd_stmt) UPDATE 1 UPDATE main_view SET b = 32 WHERE a = 21 AND b = 31 RETURNING a, b; This is a trigger on a view. I'm too tired to figure out whether or not this is truly cause for concern right now, though -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: