In a previous command, I foolishly wrote:
alter table UserInfo
add column gcal_id integer references GoogleCal on delete cascade
I've since realized that I don't want on delete cascade. How do I alter gcal-id in UserInfo to no longer have that constraint without losing the information saved in current entries?
Happily, it's fairly simple.
First \d+ UserInfo to see the constraint name, which will appear below the table's column definitions.
In your case it will probably be something like
Foreign-key constraints:
"userinfo_gcal_id_fkey" FOREIGN KEY (gcal_id) REFERENCES googlecal(id) ON DELETE CASCADE
Then, just drop and re-add the constraint in one command:
ALTER TABLE UserInfo
DROP CONSTRAINT userinfo_gcal_id_fkey,
ADD CONSTRAINT userinfo_gcal_id_fkey FOREIGN KEY (gcal_id) REFERENCES googlecal(id);
omitting the ON DELETE CASCADE part.
Related
ALTER EMPLOYEE
DROP CONSTRAINT MGR_SSN
Change all SSN ON UPDATE CASCADE
When an employee’s SSN is updated
- then propagate that change to all pertinent FKs
Link to DB: https://www.db-fiddle.com/f/wCwvN6pFq2cXvfuE57QTum/0#&togetherjs=8aityz4DAt
If you need to update a primary key, your DB design is not good.
That being said, it is possible to add a foreign key to a table with the constraint you have given. See below (I have added a ON DELETE SET NULL).
I repeat: I recommend you review your DB design.
ALTER TABLE Employee
ADD FOREIGN KEY (Mgr_SSN) REFERENCES Employee(SSN) ON DELETE SET NULL ON UPDATE CASCADE
I have a table named base_types that contains this constraint:
ALTER TABLE public.base_types
ADD CONSTRAINT base_type_gas_type_fk FOREIGN KEY (gas_type)
REFERENCES public.gas_types (gas_type) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
And I have a table named alarm_history that contains five constraints, including this one:
ALTER TABLE public.alarm_history
ADD CONSTRAINT alarm_history_device_fk FOREIGN KEY (device)
REFERENCES public.bases (alarm_device) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
I am trying to convert a database from one that didn't bother with anything weird and useless like constraints into one that uses them. I am beginning with this script:
delete from gas_types;
select conversion.convert_base_types();
alter table base_types validate constraint base_type_gas_type_fk;
select conversion.convert_alarm_history();
alter table alarm_history validate constraint alarm_history_base_fk;
alter table alarm_history validate constraint alarm_history_charge_fk;
alter table alarm_history validate constraint alarm_history_cooler_fk;
alter table alarm_history validate constraint alarm_history_device_fk;
alter table alarm_history validate constraint alarm_history_furnace_fk;
I duly get an error message telling me that the gas_type field in my new base_types record doesn't match anything in the gas_types table, since the gas_types table is empty. But if I comment out the base_types commands, I get 18,000 nice, shiny new records in the alarm_history table, despite the fact that every single one of them violates at least one of that table's five foreign key constraints, since all of the tables those keys are referring to are empty. I need to ensure that my converted data is consistent, and therefore I need to validate my constraints, but that's obviously not happening. Why not?
Since the constraints above are created as DEFERRABLE INITIALLY DEFERRED, they are not checked until the DML statements (your delete statement) are committed or in your case you until you explicitly validate the constraint.
This is the normal and expected operation of an initially deferred deferrable constraint.
To change this functionality within your current transaction you can issue a SET CONSTRAINTS command to alter this:
SET CONSTRAINTS alarm_history_device_fk IMMEDIATE;
delete from gas_types;
Which should raise a foreign key violation alerting you earlier that you have data dependent on the records you are tying to delete.
I have a table with a foreign key reference and I had added a on_delete_cascade condition with that foreign key.
I don't need the rows to be deleted even if the foreign key object gets deleted.
How can I change the drop condition without have to drop the column?
Just drop the conatraint and then add it back without the ON DELETE CASCADE clause:
ALTER TABLE some_table DROP CONSTRAINT some_key,
ADD CONSTRAINT some_key FOREIGN KEY (id) REFERENCES tab(a_id);
Check what the real experts wrote by reading here:
https://www.postgresql.org/message-id/CABvLTWHdT0tTygV0-O_ZgLRRAGZAg0W4zvghfF2PshAzvkAaGg%40mail.gmail.com
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'm trying to create a constraint with both on update and delete in tsql. I've tried a couple of different methods, and now I'm a little stuck & frustrated - seems so simple. I know you can't alter an existing constraint so I'm not sure about how to do this;
alter table AllowedCars
add constraint FK_AllowedCars_CarID foreign key (CarID)
references Cars(LocusID) on delete cascade,
constraint FK_AllowedCars_CarID foreign key (CarID)
references Cars(CarID) on update cascade
or this;
alter table AllowedCars add constraint FK_AllowedCars_CarID foreign key (CarID)
references Cars(CarID) on delete cascade and on update cascade
You need to drop constraint first, and then recreate it. Your second attempt was right, but you needed to remove and.
alter table AllowedCars
drop constraint FK_AllowedCars_CarID
alter table AllowedCars
add constraint FK_AllowedCars_CarID
foreign key (CarID)
references Cars(CarID)
on delete cascade
on update cascade