> You have a view or a function or something that depends on another
> You want to update the view that these depend on. Up until this
> applied, you can just drop the view and recreate it and the things
> depend on it will carry on working.
> However, after this patch you only have two choices: drop the view
> everything that depends on it disappear, or have your drop attempt
> ie. After this patch is applied, it will be essential that CREATE
> REPLACE] is implemented for all types of objects involved in the
> 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(at)postgresql(dot)org
> > [mailto:pgsql-patches-owner(at)postgresql(dot)org]On Behalf Of Rod Taylor
> > Sent: Thursday, 14 March 2002 10:50 PM
> > To: pgsql-patches(at)postgresql(dot)org
> > Subject: [PATCHES] pg_depend patch
> > While looking forward to the domain patch set being applied, I
> > pg_depend support.
> > 2 main functions, dependCreate() and dependDelete().
> > dependCreate() generates a dependence between two system objects,
> > can optionally be forced to 'always cascade' the drop for items
> > complex types, toast tables or indexes.
> > dependDelete() removes or restricts the removal of all dependent
> > 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
> > - create [ view | trigger | table | sequence | rule | operator |
> > function | aggregate ] need to record dependencies on creation
> > - 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
> > tables, indexes, etc) are never the same. Solution is to not
> > implicit cascades, or potentially to mark specific implicit
> > '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
> > tree something else depended on an object I wanted to drop. A
> > was an index, function, type loop. Dropping them without
> > a CommandCounterIncrement() would cause double tuple update
In response to
pgsql-patches by date
|Next:||From: Alvaro Herrera||Date: 2002-03-16 01:59:32|
|Previous:||From: Rod Taylor||Date: 2002-03-15 12:20:38|
|Subject: Re: pg_depend patch|