Thanks for looking. David Rowley wrote:
> So, if that works for ATTACH, then can't pg_dump just > create each of the partition's indexes first, then create the > partitioned table's partition index, and that command would just go > through checking each partition similar to how ATTACH would work. That was my first thought too (and I actually implemented it like this before the current approach). But there's a small problem: if a partition exists which *doesn't* have the index, restoring things this way would create the index in that partition too, which is unwanted because the end state is different to what was in the dumped database. This is because the command is either recursive (finds a matching index and attachs it, or create a new one) or not recursive (does not look at children at all). But a command that is partially recursive (attach any matching index, but do nothing if none exists) would be way too confusing, ISTM. Another small issue is that each partition might have two matching indexes, maybe because one was in the process of being removed; how would CREATE INDEX at restore time know which one to attach? It could do so by choosing arbitrarily, but that doesn't seem reliable. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
