On 16.9.2013 15:50, Adrian Klaver wrote: > On 09/16/2013 04:57 AM, Ladislav Lenart wrote: >> On 16.9.2013 13:26, Alban Hertroys wrote: > >>> >>> Wouldn't it be much easier to define an FK constraint with ON DELETE CASCADE? >>> With that, you only need to worry about which rows you delete from the >>> parent table and dependant children will be removed automatically. >> >> >> Hello. >> >> I don't quite follow. Having item.item_type1_id FK with ON DELETE CASCADE would >> delete ITEM (the parent) when ITEM_TYPE1 (the child) is deleted. You suggests >> the opposite direction. > > http://www.postgresql.org/docs/9.3/interactive/sql-createtable.html > > "..In addition, when the data in the referenced columns is changed, > certain actions are performed on the data in this table's columns. The > ON DELETE clause specifies the action to perform when a referenced row > in the referenced table is being deleted. .." > > "..CASCADE > Delete any rows referencing the deleted row, or update the values of the > referencing column(s) to the new values of the referenced columns, > respectively. > .." Hello. Thank you but I have read this in the official documentation before posting my (previous) reply. So to quote the important bit about CASCADE: Delete any rows referencing the deleted row My example defines the table item with FK to the table item_type1 and FK to the table item_type2. Specifying anything on these two constraints does not help one bit when I delete an item, because item_type1 nor item_type2 does not reference any... Therefore I suspect that Alban Hertroys had a different model in mind where: * item would not have any FKs, * item_type1 would have FK to item, * item_type2 would have FK to item? I just wasn't sure, hence I have asked him for a more detailed answer. However, I am pretty sure ON DELETE CASCADE would not help in my current setup. Ladislav Lenart -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
