Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reported number of objects dropped

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> In the case of the collate tests, these are the 17 objects I can see
> with ignore_system_indexes=off, once I remove the "\set VERBOSITY
> terse" line from the end of collate.sql:
> ...
> drop cascades to table collate_test23
> drop cascades to table collate_test4
> drop cascades to table collate_test5
> ...

> In the case of ignore_system_indexes=on, I see the same 17 entries, in
> addition to these 3 (20 total):
> drop cascades to table collate_test23 column f1
> drop cascades to table collate_test4 column b
> drop cascades to table collate_test5 column b

Ah, I think it's just an order-of-visitation issue then. There are
dependencies at both the column and whole-table level, specifically

schema collate_tests -> table collate_test4
schema collate_tests -> domain testdomain_p -> column collate_test4.b

I think if we already know that table collate_test4 is scheduled to be
deleted, we just ignore column collate_test4.b when the recursion reaches
that ... but if we visit those two things in the other order, then both
will be reported as deletion targets. And it's not surprising that
disabling indexscans on pg_depend changes the visitation order.

This makes me realize that the "\set VERBOSITY terse" hack is not
really as bulletproof a way of preventing regression test diffs
during DROP CASCADE as I'd imagined :-(

regards, tom lane