From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrzej Mazurkiewicz <andrzej(at)mazurkiewicz(dot)org> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inheritance of foregn key constraints. |
Date: | 2014-03-21 14:14:03 |
Message-ID: | 15558.1395411243@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrzej Mazurkiewicz <andrzej(at)mazurkiewicz(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-03-21 14:44:29 | Re: QSoC proposal: Rewrite pg_dump and pg_restore |
Previous Message | Kohei KaiGai | 2014-03-21 14:10:29 | Re: Creating tables for columns |