Re: Inheritance of foregn key constraints.

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

In response to

Responses

Browse pgsql-hackers by date

  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