Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped - Mailing list 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