Re: Dependency / Constraint patch

> >> I'm also somewhat uncomfortable with the notion of "implicit
> >> dependencies" (alwayscascade = true) that you've invented; this seems
> >> like a bad idea to me, but I haven't quite worked out why I don't like
> >> it.
>
> > Certainly allows for removal of a large portion of the 'drop this too'
> > code that was lying all over the place.
>
> Yeah, but having to instead write "make this dependency too" code seems
> like it largely cancels out in terms of code bulk and reliability.

Thats true -- but the code removed was certainly larger.

> Special-case code makes it easier to do the right thing (whatever we
> decide that to be) in special cases...

Most of this was in dropping a heap (toast tables, indices, constraints,
...) and the array type entry to a type entry.  They all appeared to
have to go out of their way to seek down and destroy anything using
them.  In the array type example, it even depended on naming
convention.  I think it's somewhat more generic -- but could be much
better if circular dependencies were allowed (see below) as it could
RESTRICT drops of a toast table or complex type on a table or CASCADE
them when appropriate.

> BTW, there were a number of places where it seemed that you were trying
> to avoid creating circular dependencies --- is there a problem with
> doing that?  I think it's a situation that we will have to be able to
> cope with.

Yeah.  Circular dependencies right now cause a never ending loop when
dropping them.  I tried reversing the order in dependDelete (move calls
to self to the end) but that caused lots of problems with items
expecting.  It really needs to keep a list of already found dependencies
and not attempt to drop them again.

If it kept a list and passed it into each dependDelete call (from
itself) that would help.  Perhaps it should be broken up into 2
functions.  One facing externally, and one static that does the
recursive dirty work.

> > Did you want a new patch with the above changes applied?  I would expect
> > a direct string replacement would do the job.
>
> Nah, I can hack it up myself easily enough; I've already identified a
> bunch of smaller changes to make (coding style issues mainly).

If you don't mind sending me back a patch with all of the changes when
complete, I'd appreciate it.  I'm still learning most of the basics, but
being able to see the changes made without digging through a bunch of
files on the cvsweb interface would be useful.