Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> On Wed, Apr 16, 2025 at 6:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Or we could do what Jian suggested and just not emit any dropStmt
>> for child indexes. I continue to fear that that will have
>> undesirable side-effects, but I have to admit that I'm not sure
>> what. The fact that the backend will automatically drop the
>> child index if we drop either its parent index or its table
>> seems to cover a lot of the edge cases ... but does it cover
>> all of them?

> If pg_dump not produce "DROP INDEX IF EXISTS child_index;"
> then we are actually tests drop parent index will cascade to child index.

That's only true if we emit a DROP for the parent index.
What's bothering me is the idea that a selective restore might
not drop either the parent index or the index's table, and yet
expect that this child index went away (and should be restored).
But I don't think we have any restore selectivity modes that
would make it easy to hit that corner case.

However, this asymmetry is not pg_dump's fault; it's being forced
on us by the backend's choice to not allow detaching/dropping an
index once it's been attached to a partitioned index. So after
sleeping on it, I don't see that we have an alternative that is
better than what you proposed. I pushed it after doing some work
on the comments.

regards, tom lane