jian he <jian.universality@gmail.com> writes:
> On Wed, Apr 16, 2025 at 6:51 AM Tom Lane <tgl@sss.pgh.pa.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
