On Thu, Dec 7, 2017 at 4:57 PM, David Rowley <david.row...@2ndquadrant.com> wrote: >> Sure, that would fix the problem I'm concerned about, but creating the >> parent index first, as a shell, and then creating each child and >> attaching it to the parent *also* fixes the problem I'm concerned >> about, and without dragging any bystander objects into the fray. > > That's true, but is it worth inventing/maintaining an ATTACH syntax > for that? It's not a very common case that multiple matching indexes > existing. If it is worth it, do we need DETACH at all?
I think it is totally worth it. A little piece of extra DDL syntax isn't that really costing us anything. Your proposed approach probably still has obscure failure cases - e.g. I bet the deadlock-avoidance logic in parallel restore won't know about the dependency on a seemingly-unrelated object. Also, the use of a seemingly-useless REPLACE syntax in every dump file will probably confuse at least a few users, and maybe a few developers, too. I think there is considerable value, both for the system and for the humans who use it, in having something that has *exactly* the semantics we want rather than *almost* the semantics we want. I suppose if we want to get cute, we could have ONLY the ATTACH syntax; if you attach an index for a partition that already has an index attached, that could mean attach to the new one instead of the old one (i.e. replace). But I would just add support for both ATTACH and REPLACE and call it good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
