Re: avoid circular references

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