Re: Dependency / Constraint patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rbt(at)zort(dot)ca>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Dependency / Constraint patch
Date: 2002-06-25 20:34:02
Message-ID: 10599.1025037242@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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

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

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:

> this->dependsOn(that);

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

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
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