Jerome,
> Each object can contain one or many other objects from the same
> table, so I guess this relationship can be expressed with something
> like :
This is called a "tree structure".
> CREATE TABLE contains (id SERIAL PRIMARY KEY NOT NULL,
> containerid INTEGER REFERENCES objtable(idobj),
> contentid INTEGER REFERENCES objtable(idobj) );
This is overcomplicating things, unless a single object can belong to multiple
containers, which would strike me as peculiar. Easier just to have a
"containerid" in the objtable, which is your basic Proximity List.
But of course, maybe I'm not understanding you and you do have multiple
inheritance.
> What I would like is to be able to avoid circular references :
>
> - an object can't contain itself.
>
> - an object can't contain one of its containers.
>
> So I'd like to know how to create additionnal integrity constraints
> to solve this problem, and especially what syntax I should use.
Best to use some kind of recursive function. I do this for a calendaring
setup with event templates, where events can have multiple (possible) parents
and multiple children. Just write a pl/pgSQL function which reverse-traces
the parentage of the new object, looking for copies of itself.
> I thought about creating a rule but maybe the best is a trigger
> (I'm not sure I really understand the difference) if I see
> what happens when I create new tables. But what can I do in
> my trigger to have PostgreSQL understand there's an integrity
> violation ?
A trigger. Just use a BEFORE trigger and raise an exception if a self-parent
is found.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
