Automatic retention and referencing Foreign Key constraints

[kmustkivi]

Hello,

The automatic drop of a partition fails if there are existing Foreign Key constraints that are referencing the partition being dropped. Asking if it has been considered to add a logic to remove the referencing FKs to the partition into the function drop_partition_time for example? Maybe it is a bad idea? I would prefer this to be part of the partition maintenance procedure rather than building an external archiving logic. But maybe it has already been considered and found to be problematic.

Exploring with PG 18.1 and Partman: 5.3.1

With best regards,

KM

[keithf4]

The thing that needs to be figured out is how to identify which FK constraint to be dropped each time a child table is dropped. Or are you saying they should all just be dropped? That might be the simplest solution.

Working on another option as well to allow a detach before table drop.

[kmustkivi]

Right. I should have run some experiments before asking - the problem (in my case) is the inherited Foreign Key constraint which cannot be dropped (of course) only for some partitions but has to be dropped for the entire partitioned table. So the only real solution is to detach and drop the qualifying partitions in correct order - first the partitions in referencing relations, finally the partitions in the relation that are referenced.

…

On Fri, Feb 27, 2026 at 5:27 PM Keith Fiske ***@***.***> wrote: The thing that needs to be figured out is how to identify which FK constraint to be dropped each time a child table is dropped — Reply to this email directly, view it on GitHub <#849 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BM37P2GPEVDITN64UAP35CL4OBO4RAVCNFSM6AAAAACWBXFXQ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJUHAYTCNY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Kristjan Mustkivi Email: ***@***.***