Dependencies with pg_depends - Mailing list pgsql-hackers

I'd like to take a stab at getting dependency tracking going.  Have a
week of evenings ahead of me and a couple of weekends...

My short term goal is simply to have all items which can hold comments
(most) store what they depend on during their creation, and to remove
those associations on their destruction.  No visible changes to the
frontend or users in any shape or form, but will allow stuff to be
built on it.

Long term goal is to implement RESTRICT and CASCADE on all of those
items (in particular those damn SERIALs, which should have the side
effect of allowing me to shrink my NAMEDATALEN value (avoids naming
conflicts) ).

To accomplish this I'm going to create a table called pg_depends which
looks very similar to pg_description doubed.

classoid - Class of the depender
objoid - ID of the depender object
objsubid - SubID (See pg_description)
depclassoid - Class of the dependee
depobjoid - ID of the dependee object
depobjsubid - SubID of the dependee
WITHOUT OIDS

It's assummed there is only one kind of dependency, that which is
required.  No optional relations.  Dependencies are also direct, that
is the smallest step possible to the immediate item.  A CHECK
constraint may depend on 2 columns of a table, but never on the table
itself.  The table can be modified without affecting the check -- add
column -- but the columns cannot.


The postgresql backend will require a few functions to operate
dependencies.

dependCreate(depender, dependee)   - Create a dependency between a depender and dependee.   - Called during the
creationof any objects -- possibly several
 
times -- to show dependencies on various items (columns on types for
example, or types on functions   - Assumes both the depender and dependee exist (does no lookups to
ensure they do).

dependUpdate(old, new)   - Enables mapping an old Object Address (classid, objid, objsubid)
to a new one   - Is this even required?  I'm thinking CREATE OR REPLACE type
stuff -- but those shouldn't change the IDs right?

dependDelete(object being dropped, RestrictOrCascade)   - Drop a dependency between a depender and dependee.   - Enable
Restrictions(abort transaction on found dependency
 
during a delete)   - Enables cascades (drop everything in our way via the big switch
statement)   - Would it be better to drill down to the end points and start
dropping or start from the top in the event of an object which cannot
be dropped?

NOTES:
- Speed hit.  All drops and creations will take a small speed hit.
Won't affect selects, inserts, deletes or updates though.
- Syntax changes in alot of places to add RESTRICT OR CASCADE type
elements.  Do we go with restrict by default and not enforce?  I'd
prefer to enforce the user to choose as thats spec.
- Creation of src/backend/catalogs/depend.c for the above functions.
- Did I miss anything?
- pg_depends will be preloaded with association data between
functions, types and attributes (not looking forward to this step)
- Although items may reference others directly (tables to columns) I'm
going to add it to pg_depends anyway as a second copy HOWEVER when
processing with dependDelete() it will skip testing the columns, and
move directly to the columns dependencies.  Is this silly?  Kinda a
special case.  Can anything depend on a table directly (rather than a
column within a table?).  Types to functions should definately be in
here (drop the function, lose the type on cascade)
--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.