While looking forward to the domain patch set being applied, I started
pg_depend support.
2 main functions, dependCreate() and dependDelete().
dependCreate() generates a dependence between two system objects, and
can optionally be forced to 'always cascade' the drop for items such as
complex types, toast tables or indexes.
dependDelete() removes or restricts the removal of all dependent objects
on the one being dropped informing the user of the cascade.
Affected areas (thus far):
- drop type
- drop view
- drop trigger
- drop sequence
- drop rule
- drop operator
- drop language
- drop function
- drop index
- drop aggregate
- create language
- create index
- create type
Type to array type relation is now done using an 'always cascaded'
dependent relationship.
To be completed (currently uses old 'ignorance is bliss' methods):
- Drop serial on column drop (tables cascade to drop all columns)
- Drop triggers via always cascade relationship (uses hard coded method)
- create [ view | trigger | table | sequence | rule | operator |
function | aggregate ] need to record dependencies on creation time.
- RESTRICT / CASCADE keywords should be used with drop statements
(Always restricts, unless it's an implicit cascade)
- BOOTSTRAPPED objects need their dependencies recorded.
Problems:
Regression tests can fail as the OID in names of some objects (toast
tables, indexes, etc) are never the same. Solution is to not mention
implicit cascades, or potentially to mark specific implicit cascades as
'silent drop' while others are 'informed drop'.
Thanks for taking a look. I'm sure I did some weird stuff.
BTW. In dependDelete() each loop rescans incase while running down the
tree something else depended on an object I wanted to drop. A good case
was an index, function, type loop. Dropping them without rescanning and
a CommandCounterIncrement() would cause double tuple update issues.
