Re: pg_depend patch

> 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(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
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.
> >
>
>