From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Trigger violates foreign key constraint |
Date: | 2023-10-02 14:11:59 |
Message-ID: | a3c8f66a2d89270eef77da9ba485949a49cdd8e9.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION silly();
>
> > The trigger function cancels the cascaded delete on "child", and we are left with
> > a row in "child" that references no row in "parent".
>
> Yes. This is by design: triggers operate at a lower level than
> foreign keys, so an ill-conceived trigger can break an FK constraint.
> That's documented somewhere, though maybe not visibly enough.
>
> There are good reasons to want triggers to be able to see and
> react to FK-driven updates, so it's unlikely that we'd want to
> revisit that design decision, even if it hadn't already stood
> for decades.
Thanks for the clarification. I keep learning.
I didn't find anything about that in the documentation or the
READMEs in the source, but perhaps I didn't look well enough.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hill | 2023-10-02 14:28:58 | pg*.dll and *.pdb files in psqlODBC have no version numbers |
Previous Message | Tom Lane | 2023-10-02 13:49:53 | Re: Trigger violates foreign key constraint |