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

Show quoted text

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

Show quoted text

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.

Show quoted text