Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
delete on tables with rules #130
I have a table where I have a rule like this:
CREATE OR REPLACE RULE soft_delete AS ON DELETE TO "frontend_to_product" WHERE old."comitted_status" IS NOT NULL DO INSTEAD UPDATE "frontends"."frontend_to_product" f_p SET "desired_status" = NULL, "mod_hash" = NULL WHERE (f_p."id_frontend", f_p."id_product") = (old."id_frontend", old."id_product");
the goal of this is to delete only items that have a committed status of NULL and otherwise set the desired_status to NULL.
DELETE FROM "frontend_to_product" WHERE "id_frontend"='666040' AND "id_product"='14575';
but when I want to save the changes I get the error "Could not save changes – The query did not affect the expected number of rows. The transaction was rolled back."
As a side note:
DELETE FROM "frontend_to_product" WHERE ("id_frontend", "id_product") = ('666040', '14575');
Good point, thanks for the detailed explanation.
I've just added a button to commit the transaction anyway:
I've also added a hidden preference to disable the check altogether. Type the following command in Terminal if you want Postico to just ignore this error:
Concerning your suggestion for writing the query, is it always possible to write queries in that way? Is the row constructor syntax equivalent to using AND? The PostgreSQL documentation contains this puzzling quote: "Every row element must be of a type which has a default B-tree operator class" (see here), so I'm not sure I can always write the query like you suggested. (I don't want to change it since the way I curently do it seems to work)
the new build works for me.
I understand the "don't change it, if it works" argument and one doesn't look at the generated sql statement so often anyway.
I think it does work all the time since a primary key is a
It took me a while to find it but I think the relevant part of the documentation is this one:
As I understand it a B-tree index implies a B-tree operator for every column (not sure about the default part).
You are right, it probably works when there's a primary key. I'll leave it as is though, because the same code path also handles the case when all columns are compared (for tables without a primary key). Also, I remember there were some issues with row constructors on an old version of PostgreSQL, but I don't remember the details.
The new commit behavior is now released in version 1.0.1