Cascade delete postgres12/14/2023 Why would one ever want a query to be refused like that? And "CASCADE" isn't even the only option (besides none) there are multiple other values you can use which cause various behaviour (which I don't understand). I'm basically confused about the entire concept of "ON UPDATE" and "ON DELETE". In the test2 table, again as I understand it, if the "othertable" either changes the "id" column values, or deletes any record(s), that means that PostgreSQL will refuse to perform the query if there are records in test2 which reference the ones being modified. This seems, on the surface, like what should be the default behaviour. In the test1 table, as I understand it, if the "othertable" either changes the "id" column values, or deletes any record(s), that means that the referenced records in the test1 table will either be updated or deleted. Since this is not done by default, there must be a reason for this! After all, the default behaviour is always (or at least should always be) the most commonly needed behaviour: CREATE TABLE "test2"įOREIGN KEY (referenceid) REFERENCES "othertable" (id) This code goes out of its way to explicitly add the technically "unnecessary" part: "ON UPDATE CASCADE ON DELETE CASCADE". Example: CREATE TABLE "test1"įOREIGN KEY (referenceid) REFERENCES "othertable" (id) ON UPDATE CASCADE ON DELETE CASCADE However, something which has always confused me is whether or not I should be explicitly setting the "ON UPDATE" and "ON DELETE" features (in lack of a better term). I understand what foreign keys are, and have made a point of including them wherever they make sense for all my database tables that I design.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |