Re: Introducing find_all_inheritors_ordered()

> On Sep 8, 2026, at 06:16, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> On Mon, 07 Sep 2026, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> My understanding is that PG doesn’t intend to support cyclic inheritance. The code explicitly rejects it:
>
> To me it seems like that it discourages it and tries to prevent it
> where it's possible to do so with reasonable effort, but it ends up
> trying to support it because it's a valid scenario that can happen in
> some workloads (as long as that also doesn't require too much effort).

I think an important problem is that, in your earlier example, two users independently execute ALTER TABLE … INHERIT, but the commands together create an inheritance cycle without either user being notified. Even if PG currently tolerates this, I think preventing it would be preferable.

As Tom pointed out, cycles can also cause problems elsewhere in the system. So I agree that we should investigate whether we can prevent their creation at a reasonable cost.

>
>> A cycle can cause it to exceed the stack depth limit, so it is reasonable to fail the command when a cycle is detected.
>
> Or it might succeed in other cases.
>
> Here's a repro with an isolation test. Perm 1 fails on master, works
> with the patch. Perm 2 works on master, fails with the patch.
> We could improve this by only using the new function in the enforced
> direction, I don't have a better idea currently. With that, the
> patched behavior would be the same as on master.
>

This is a valid point. ENFORCED doesn’t need to check parents’ enforceability, so we can still use find_all_inheritors() to tolerate potential cycles and use find_all_inheritors_ordered() only for NOT ENFORCED. This preserves master’s success/failure outcomes in your test, while replacing the stack-depth error with an explicit cycle error. I have updated the code in v3.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/