From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrzej Mazurkiewicz <andrzej@mazurkiewicz.org>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Inheritance of foregn key constraints.
In-reply-to: <1523734.6NloWteI3S@tata>
References: <1523734.6NloWteI3S@tata>
Comments: In-reply-to Andrzej Mazurkiewicz <andrzej@mazurkiewicz.org>
 message dated "Fri, 21 Mar 2014 11:32:56 +0100"
Date: Fri, 21 Mar 2014 10:14:03 -0400
Message-ID: <15558.1395411243@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andrzej Mazurkiewicz <andrzej@mazurkiewicz.org> writes:
> My patch need one change that might be of significance.
> A type of the depencencies (pg_depend) among the FK constraint (pg_constraint) 
> and the corresponding "RI_ConstraintTrigger" triggers has to be changed from 
> DEPENDENCY_INTERNAL to DEPENDENCY_AUTO.

So in other words, somebody could (accidentally or maliciously) break the
constraint by dropping one of its implementation triggers.  I doubt that's
acceptable.

> If this modification is not applied, the detail child table cannot be dropped 
> without prevous dropping the whole FK constraint because the removing 
> operation depend on the FK constraint of its parent table.

Dropping a child table is going to have much larger problems than that,
no?  What about the values in the child table --- don't you risk orphaning
referencing rows?  Or are you only supporting this on the referencing
side?

In any case, it seems like DROP TABLE could remove the dependency entries
for itself, rather than taking the risk of weakening the dependency type.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers