Thread: pg_depend patch
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.
Attachment
I was thinking. With a patch such as this, this is the situation: You have a view or a function or something that depends on another view. You want to update the view that these depend on. Up until this patch is applied, you can just drop the view and recreate it and the things that depend on it will carry on working. However, after this patch you only have two choices: drop the view and have everything that depends on it disappear, or have your drop attempt denied by restrict. ie. After this patch is applied, it will be essential that CREATE [OR REPLACE] is implemented for all types of objects involved in the dependency hierarchy. Is this correct? Chris > -----Original Message----- > From: pgsql-patches-owner@postgresql.org > [mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Rod Taylor > Sent: Thursday, 14 March 2002 10:50 PM > To: pgsql-patches@postgresql.org > Subject: [PATCHES] pg_depend patch > > > 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. >
Christopher Kings-Lynne writes: > You have a view or a function or something that depends on another view. > You want to update the view that these depend on. Up until this patch is > applied, you can just drop the view and recreate it and the things that > depend on it will carry on working. No they won't. That's exactly the reason why we need this dependency tracking. -- Peter Eisentraut peter_e@gmx.net
Ahh.. Thanks. I'm completely confident it'll work however when the grammer portions are added and everything is tracked at creation time. It's been setup so the calling function must pass the keyword currently, it's a simple matter of pulling it from the grammer. However, I'll configure that element (and the domain stuff) to actually use it -- although they won't cascade very far until the items they're cascading through also have the ability. -- Rod Taylor This message represents the official view of the voices in my head ----- Original Message ----- From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> To: "Rod Taylor" <rbt@zort.ca> Sent: Thursday, March 14, 2002 8:32 PM Subject: RE: [PATCHES] pg_depend patch > > 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) > > If you want something to experiement with, the ALTER TABLE/DROP CONSTAINT > code currently REQUIRES the restrict/cascade keyword but just ignores it... > > Chris > >
> You have a view or a function or something that depends on another view. > You want to update the view that these depend on. Up until this patch is > applied, you can just drop the view and recreate it and the things that > depend on it will carry on working. > > However, after this patch you only have two choices: drop the view and have > everything that depends on it disappear, or have your drop attempt denied by > restrict. > > ie. After this patch is applied, it will be essential that CREATE [OR > REPLACE] is implemented for all types of objects involved in the dependency > hierarchy. > Is this correct? That would be correct. And with good reason. If you have a function which depends on a view, and you drop and re-create the view you also need to recompile the function. Right now we don't (also need to drop and recreate function). Atleast now (soon) you will be able to find out what depended on the view in the first place to tell them to 'reset' if necessary. > > -----Original Message----- > > From: pgsql-patches-owner@postgresql.org > > [mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Rod Taylor > > Sent: Thursday, 14 March 2002 10:50 PM > > To: pgsql-patches@postgresql.org > > Subject: [PATCHES] pg_depend patch > > > > > > 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. > > > >