Re: Dependency / Constraint patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: Dependency / Constraint patch
Date
Msg-id 10599.1025037242@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dependency / Constraint patch  (Rod Taylor <rbt@zort.ca>)
Responses Re: Dependency / Constraint patch  (Rod Taylor <rbt@zort.ca>)
List 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



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reduce heap tuple header size
Next
From: Jan Wieck
Date:
Subject: Re: Reduce heap tuple header size