Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails - Mailing list pgsql-hackers

From Tender Wang
Subject Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date
Msg-id CAHewXNnuCNiy5VBOVWPTXwxqHRMXKZ-Z_6hT9koQXAS9PBdVRQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
List pgsql-hackers


Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年7月19日周五 21:18写道:
Hello,

I think the fix for the check triggers should be as the attached.  Very
close to what you did, but you were skipping some operations that needed
to be kept.  AFAICS this patch works correctly for the posted cases.

After applying the attached, the r_1_p_id_fkey1 will have redundant action
triggers, as below:
postgres=# select oid, conname, contype, conrelid, conindid,conparentid, confrelid,conislocal,coninhcount, connoinherit from pg_constraint where oid = 16402;
  oid  |    conname     | contype | conrelid | conindid | conparentid | confrelid | conislocal | coninhcount | connoinherit
-------+----------------+---------+----------+----------+-------------+-----------+------------+-------------+--------------
 16402 | r_1_p_id_fkey1 | f       |    16394 |    16392 |           0 |     16389 | t          |           0 | f
(1 row)

postgres=# select oid, tgrelid, tgparentid, tgconstrrelid, tgconstrindid, tgconstraint from pg_trigger where tgconstraint = 16402;
  oid  | tgrelid | tgparentid | tgconstrrelid | tgconstrindid | tgconstraint
-------+---------+------------+---------------+---------------+--------------
 16403 |   16389 |      16400 |         16394 |         16392 |        16402
 16404 |   16389 |      16401 |         16394 |         16392 |        16402
 16422 |   16389 |          0 |         16394 |         16392 |        16402
 16423 |   16389 |          0 |         16394 |         16392 |        16402
(4 rows)


--
Tender Wang

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Allow logical failover slots to wait on synchronous replication
Next
From: Michael Paquier
Date:
Subject: Re: Incremental backup from a streaming replication standby