Is it possible to delete the row "on cascade" in postgres if there is a restrict constraint?
And is it possible to change all restrict constraints to cascade constraints automatically?
Neither is possible. Your options would be to:
DROP CONSTRAINT, DELETE and ADD CONSTRAINT
or
DROP CONSTRAINT, ADD CONSTRAINT ... ON DELETE CASCADE and DELETE
From PostgreSQL Documentation you can see what alterations can be done on table constraints:
I. SQL Commands - ALTER TABLE
Related
I'm using AWS Aurora Postgres and using DMS to migrate from RDS postgres to Aurora PG. In order to perform the FULL LOAD I want to disable foreign key constraints and triggers on all the objects. I'm able to disable triggers but couldn't find a way to disable constraints.
Below doesn't work:
ALTER TABLE so_items DISABLE CONSTRAINT so_items_so_id_fkey;
It throws:
ERROR: syntax error at or near "CONSTRAINT"
LINE 1: ALTER TABLE so_items DISABLE CONSTRAINT so_items_so_id_fkey;
^
SQL state: 42601
Character: 30
Setting "session_replication_role" = "replica" in the parameter group didn't work. While the DMS task tries to truncate the table part of preparation it still fails with foreign key violation errors.
Please advise any workarounds.
Note: I couldn't do below since in RDS I do not have permissions to do so even with master account:
alter table so_items disable trigger ALL;
ERROR: permission denied: "RI_ConstraintTrigger_c_16520" is a system trigger
SQL state: 42501
You shouldn't modify the triggers a Postgres constraint relies on. This is an implementation detail for which you shouldn't care about.
You cannot disable constraints, really.
To turn constraints temporarily off, you can defer the constraint check to the end of transactions:
ALTER TABLE so_items ALTER CONSTRAINT so_items_so_id_fkey DEFERRABLE INITIALLY DEFERRED;
With that modification the constraint is evaluated after a modification at the end of the current transaction. This will allow you to break the constraint inside of a transaction.
You may DROP CONSTRAINTs
ALTER TABLE so_items DROP CONSTRAINT so_items_so_id_fkey;
which will delete it permanently.
Edit: It is also possible to disable the triggers which also affects the foreign key constraints of the table
ALTER TABLE so_items DISABLE TRIGGER ALL;
But when you are re-enabling the triggers afterwards, the foreign keys are not checked. This might lead to invalid / inconsistent foreign keys in the database.
For Postgres :-
It is easier to disable all triggers with:
SET session_replication_role = 'replica';
And after migration reenable all with
SET session_replication_role = 'origin';
When dropping constraints from a postgres table , How to know the safest order to drop the constraints. Like ,
1) The foreign key constraints can be dropped first [as they have to be droppped before primary key constraint]
Then the order of removing the constraints can be in any order . like check constraint, unique constraint, not nulls, default , primary key constraints . Am I correct
No constraint on a PostgreSQL table depends on another constraint on the same table, so the order does not matter here.
The only dependency between constraints is the dependency of a foreign key on the primary or unique key on the target table.
So you can either remove all foreign key constraints first and then all other constraints, or you can use ALTER TABLE ... DROP CONSTRAINT ... CASCADE which will automatically drop all dependent constraints, then you don't have to care about the order at all.
I have a table called "Reviews" and it references a record in a table "ReviewSetups". When I delete a ReviewSetup I was to also delete all child Reviews (so cascade delete).
I have setup the foreign key like below on the Reviews table but nothing gets deleted when I delete a parent ReviewSetup.
I have other entities in by db as well which I migrated with a FK in exactly the same way and those work fine.
Does anyone have an idea what is going on here?
EDIT
Here's the code:
-- Foreign Key: "FK_Reviews_ReviewSetup_Id_ReviewSetups_Id"
-- ALTER TABLE "Reviews" DROP CONSTRAINT "FK_Reviews_ReviewSetup_Id_ReviewSetups_Id";
ALTER TABLE "Reviews"
ADD CONSTRAINT "FK_Reviews_ReviewSetup_Id_ReviewSetups_Id" FOREIGN KEY ("ReviewSetup_Id")
REFERENCES "ReviewSetups" ("Id") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE;
If you had to drop database again and again, it's better to disable constraints till you find the right culprit or re-design the schema.
Disable constraints and delete data, then re-enable again.
Disable constraints :
Alter table tablename NOCHECK CONSTRAINT constraintname
Enable again:
Alter table tablename CHECK CONSTRAINT constraintname
Ended up dropping the entire db and re-running the migration from scratch. Somehow that solved it. Somewhere, somehow the config was off a bit. Really curious what was the culprit though...
In order to delete some rows referenced by a foreign key constraint without cascading on delete, I created a temporary foreign key constraint, deleted the row, and then deleted the temporary constraint:
ALTER TABLE rel_user_right
ADD CONSTRAINT temp_fk_rel_user_right_user_right_02
FOREIGN KEY (right_id) REFERENCES user_right (id)
ON DELETE CASCADE;
DELETE FROM user_right WHERE "name" LIKE '%.statusLight.%';
ALTER TABLE rel_user_right
DROP CONSTRAINT temp_fk_rel_user_right_user_right_02;
where this table already had the following constraint defined on it:
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right_02
FOREIGN KEY (right_id) REFERENCES user_right (id);
This worked fine for me, but seems to have failed on my colleague's computer. As you can see, the two FK constraints define conflicting ON DELETE behaviour. Is precedence defined in this situation, or is it non-deterministic?
Postgres allows to create two references differing only in ON DELETE clause.
I could find no information on the impact of such a case.
In my tests I was unable to cover the existing constraint with new one (i.e. DELETE was always restricted despite of the existence of the second cascading constraint).
However this behaviour is undocumented and one should not rely on it.
The normal way to proceed should be replacing the old constraint with new one:
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right_temp
FOREIGN KEY (right_id) REFERENCES user_right (id)
ON DELETE CASCADE,
DROP CONSTRAINT fk_rel_user_right_user_right;
DELETE FROM user_right WHERE "name" LIKE '%.statusLight.%';
ALTER TABLE rel_user_right
ADD CONSTRAINT fk_rel_user_right_user_right
FOREIGN KEY (right_id) REFERENCES user_right (id),
DROP CONSTRAINT fk_rel_user_right_user_right_temp;
DISABLE CONSTRAINT would be useful here, but there is no such feature in Postgres (there have been attempts to implement it, but they did not end in success). You can use DISABLE TRIGGER for it, but the above solution is simpler and more natural.
I have run into problems when restoring a PostgreSQL database schema in another server. More precisely, some of the tables don't seem to have the same foreign key constraints associated with them that they used to in the original database. For example, the ON DELETE CASCADE clause seems to have completely evaporated from all of the constraint definitions.
That's probably because the dumping procedure didn't backup the ON DELETE CASCADE clauses in your table definitions.
Firstly you should delete the foreign key constraints on your tables and then go on to altering them:
Something like the following:
ALTER TABLE ONLY *your_table* DROP CONSTRAINT your_constraint;
After that, recreate the constraints with something like:
ALTER TABLE ONLY your_table ADD CONSTRAINT your_constraint (...ON DELETE CASCADE, etc..);