From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: DELETE trigger, direct or indirect? |
Date: | 2023-02-16 16:46:27 |
Message-ID: | c0b73262-1afc-842b-1653-1671a4f9e7a5@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/16/23 05:23, Dominique Devienne wrote:
> Hi. This is a bit unusual. We have a foreign key between two tables,
> with ON DELETE CASCADE, to preserve referential integrity. But we
> apparently also need to preserve the severed reference (by natural key,
> i.e. its name), to later on reconnect the two entities after-the-fact,
> should the parent row re-appear later on (in the same transaction or not
> it still unclear).
This is going to need a more detailed description of the relationship
between the two tables:
1) The actual FK relationship.
2) What "...preserve the severed reference (by natural key, i.e. its
name)" means?
3) What information will be used to reconnect the child rows to the
parent rows?
>
> To achieve this weird requirement, I'd like to know if it is possible in
> an ON DELETE trigger to know whether the deletion is coming from a
> direct-DELETE in the "child table", or whether the deletion is coming
> from the "parent table" CASCADEd to the child table.
>
> Thanks, --DD
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2023-02-16 16:48:22 | Re: Support logical replication of DDLs |
Previous Message | Ron | 2023-02-16 16:15:50 | Re: Postgres undeterministically uses a bad plan, how to convince it otherwise? |