Re: avoid circular references - Mailing list pgsql-sql

From Josh Berkus
Subject Re: avoid circular references
Date
Msg-id 200311052115.39330.josh@agliodbs.com
Whole thread Raw
In response to avoid circular references  (Jerome Alet <alet@librelogiciel.com>)
Responses Re: avoid circular references  (Jerome Alet <alet@librelogiciel.com>)
List pgsql-sql
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


pgsql-sql by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [HACKERS] Schema boggle...
Next
From: Jerome Alet
Date:
Subject: Re: avoid circular references