| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Subject: | Re: Trigger violates foreign key constraint |
| Date: | 2024-05-08 15:14:18 |
| Message-ID: | 491828.1715181258@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
>> Perhaps we should leave the system triggers out of the discussion
>> entirely? More or less like:
>>
>> If a foreign key constraint specifies referential actions (that
>> is, cascading updates or deletes), those actions are performed via
>> ordinary SQL update or delete commands on the referencing table.
>> In particular, any triggers that exist on the referencing table
>> will be fired for those changes. If such a trigger modifies or
>> blocks the effect of one of these commands, the end result could
>> be to break referential integrity. It is the trigger programmer's
>> responsibility to avoid that.
> That's perfect!
Hearing no further comments, done like that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey M. Borodin | 2024-05-08 15:37:11 | Re: UUID v7 |
| Previous Message | Bruce Momjian | 2024-05-08 14:44:17 | Re: PERIOD foreign key feature |