Re: Dependency / Constraint patch

Rod Taylor <rbt(at)zort(dot)ca> writes:
> On Tue, 2002-06-25 at 20:34, Tom Lane wrote:
>> Another line of thought is 'referencer' and 'referencee', since in

> I'd expect this to have similar issues as depender and dependee in
> implementation.

Could be. I thought the direction of "references" might be more obvious
than that of "depends", but maybe not. Anyone else have any naming ideas?

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

The real problem is that I don't think a one-size-fits-all solution
exists for all those special-cased relationships. For example, the
relationship between a table and its rowtype (pg_type entry) doesn't
really fit the model. Unless I'm missing something, your patch doesn't
prevent someone from dropping the type without dropping the table.
Special-case code makes it easier to do the right thing (whatever we
decide that to be) in special cases...

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.

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

regards, tom lane