Re: pg_depend patch

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