Restricting and cascading deletes are the two most common options. So in your case when user removes entries from categories table then rows will be deleted from books table. So it's all about what will happen when you delete rows from Parent table not from child table. The principal advantage to the cascading-deletes feature is that it allows you to reduce the quantity of SQL statements you need to perform delete actions. If you specify this option, later when you delete a row in the parent table, the database server also deletes any rows associated with that row (foreign keys) in a child table. If you do not specify cascading deletes, the default behaviour of the database server prevents you from deleting data in a table if other tables reference it.
ON DELETE CASCADE option is to specify whether you want rows deleted in a child table when corresponding rows are deleted in the parent table. You are saying in a opposite way, this is not that when you delete from child table then records will be deleted from parent table. TRUNCATE can be used for foreign tables if supported by the foreign data wrapper, for instance, see postgres_fdw.A foreign key with a cascade delete means that if a record in the parent table is deleted, then the corresponding records in the child table will automatically be deleted. This is similar to the usual behavior of currval() after a failed transaction. Be aware that if any additional sequence operations are done on the restarted sequences before the transaction rolls back, the effects of these operations on the sequences will be rolled back, but not their effects on currval() that is, after the transaction currval() will continue to reflect the last sequence value obtained inside the failed transaction, even though the sequence itself may no longer be consistent with that. When RESTART IDENTITY is specified, the implied ALTER SEQUENCE RESTART operations are also done transactionally that is, they will be rolled back if the surrounding transaction does not commit. TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit.
After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. The triggers will fire in the order that the tables are to be processed (first those listed in the command, and then any that were added due to cascading). If ON TRUNCATE triggers are defined for any of the tables, then all BEFORE TRUNCATE triggers are fired before any truncation happens, and all AFTER TRUNCATE triggers are fired after the last truncation is performed and any sequences are reset. TRUNCATE will not fire any ON DELETE triggers that might exist for the tables. The CASCADE option can be used to automatically include all dependent tables - but be very careful when using this option, or else you might lose data you did not intend to! Note in particular that when the table to be truncated is a partition, siblings partitions are left untouched, but cascading occurs to all referencing tables and all their partitions with no distinction. Checking validity in such cases would require table scans, and the whole point is not to do one. TRUNCATE cannot be used on a table that has foreign-key references from other tables, unless all such tables are also truncated in the same command. If concurrent access to a table is required, then the DELETE command should be used instead. When RESTART IDENTITY is specified, any sequences that are to be restarted are likewise locked exclusively.
TRUNCATE acquires an ACCESS EXCLUSIVE lock on each table it operates on, which blocks all other concurrent operations on the table. You must have the TRUNCATE privilege on a table to truncate it.
0 kommentar(er)
