Re: pg_dump INDEX ATTACH versus --clean option

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2021-Jan-12, Tom Lane wrote:
>> Since there's no ALTER INDEX DETACH PARTITION, it's not entirely
>> clear what to do about this. We could possibly not emit any
>> dropStmt for partition child indexes, but that seems very likely
>> to cause problems for partial-restore scenarios.

> Yeah, it would break the case of restoring a partition that already
> exists under --clean. (Of course, if the partition doesn't exist
> already, there's no problem, since nothing is to be dropped anyway.)

> About the only thing I can think of, is to make the dropStmt use a
> plpgsql DO block that drops conditionally (only if not an index
> partition).

Don't much like that :-(. Aside from the fact that we'd then be
requiring plpgsql to exist to do a restore, I think this would
cause big compatibility problems in the future, since the DO block
would have to do some more-or-less-weird catalog query to find out
if the index is a partition. We'd be locked into guaranteeing that
that query works, pretty much forever.

I think actually the cleanest fix would be to invent ALTER INDEX DETACH
PARTITION and use that as the dropStmt for the INDEX ATTACH object.
No idea how painful that would be to do, though. I suppose it'd involve
reverting the parent index back to an invalid state.

regards, tom lane