Skip site navigation (1) Skip section navigation (2)

protected ON DELETE CASCADE

From: Murray Hobbs <murray(at)efone(dot)com>
To: pgsql-sql(at)postgresql(dot)org, pgsql-novice(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: protected ON DELETE CASCADE
Date: 2001-08-22 22:01:07
Message-ID: 3B842BA3.D7E3930D@efone.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-novicepgsql-sql
here's my problem

i have tables A, B, C, D

A <- B
A <- C <- D

i want to maintain integrity so that if A is deleted from then so is
anything referencing from B and C - no problem ON DELETE CASCADE

but if there are any D's that point back to A (through composite key in
C) i don't want the delete to go ahead - at all - i want an error
message and condition

can someone who knows the pgsql system well tell me how this is best
done

I've looked at RULE - but how do i delete the old. record (ie confirm
the delete) or conversely prevent the delete?

I've looked at TRIGGER but then i'm writing a function (in SQL?) which
is called by a trigger - again - how do i confirm or reject a delete?

or is it really the case i have to maintain the integrity externally and
write functions that deal with the children and then delete parents -
all in a single transaction - ie not use ON DELETE CASCADE, or rules, or
triggers?

and sorry for cross post but was not sure which was the best list

thanks

murray hobbs
efone.com

Responses

pgsql-novice by date

Next:From: Jason EarlDate: 2001-08-22 23:52:37
Subject: Re: Text Import
Previous:From: Jason EarlDate: 2001-08-22 20:07:04
Subject: Re: Bad timestamp external representation

pgsql-general by date

Next:From: Stephan SzaboDate: 2001-08-22 22:06:23
Subject: Re: current_timestamp wrong
Previous:From: Peter PilslDate: 2001-08-22 21:50:38
Subject: current_timestamp wrong

pgsql-sql by date

Next:From: JaydipDate: 2001-08-23 07:50:52
Subject: Help On Postgresql
Previous:From: postgresqlDate: 2001-08-22 19:37:35
Subject: just checking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group