On 8 December 2017 at 10:51, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Dec 7, 2017 at 4:43 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> And yeah, this does nothing for making sure we choose the correct >> index if more than one matching index exists on the leaf partition, >> but perhaps we can dump a series of >> >> ALTER INDEX p_a_idx REPLACE INDEX FOR p1 WITH p1_a_idx; >> ALTER INDEX p_a_idx REPLACE INDEX FOR p2 WITH p2_a_idx; >> >> ... which would be no-ops most of the time, but at least would ensure >> we use the correct index. (Likely we could fix the FOREIGN KEY >> constraint choosing the first matching index with some variation of >> this syntax) > > 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? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
