|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Rod Taylor <rbt(at)zort(dot)ca>|
|Subject:||Re: Dependency / Constraint patch|
|Views:||Raw Message | Whole Thread | Download mbox|
> The confusing part is that we deal primarily with the supporting objects
> while dealing with the dependency. Perhaps better naming would be
> 'supporter' (dependee) and 'supportee' (depender) which reverses the
> logic -- more conventional? That is, pass around the opposite of a
Hmm, that might help. I was thinking of "depender" and "master".
> Perhaps simply supporter and depender?
That could work too; two positive identifications instead of a positive
Another line of thought is 'referencer' and 'referencee', since in
general the dependent object is going to have an actual link to the
independent object somewhere in its definition. Basically what
pg_depend is doing for us is providing an index that lets us trace those
links in the reverse direction efficiently.
> I was considering createDependency(this, that) myself. dependsOn seems
> like it should be:
Yeah, it would work better in a C++-ish syntax, but we don't have that
luxury. My problem with either dependCreate or createDependency is that
they don't give you a cue about the argument ordering, and with such an
easily-reversed relationship I think a cue is important.
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
regards, tom lane
|Next Message||Jan Wieck||2002-06-25 20:42:08||Re: Reduce heap tuple header size|
|Previous Message||Tom Lane||2002-06-25 20:20:36||Re: Reduce heap tuple header size|