On Tue, Dec 5, 2017 at 3:53 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > I'm not hugely concerned about that. It's not a new problem and it's > not a problem that I recall seeing anyone complain about, at least not > to the extent that we've ever bothered to fix it. > > The existing problem is with FOREIGN KEY constraints just choosing the > first matching index in transformFkeyCheckAttrs() > > We can see the issue today with: > > create table t1 (id int not null); > create unique index t1_idx_b on t1 (id); > create table t2 (id int references t1 (id)); > create unique index t1_idx_a on t1 (id); > > <pg_dump> > <pg_restore> > > # drop index t1_idx_a; > ERROR: cannot drop index t1_idx_a because other objects depend on it > DETAIL: constraint t2_id_fkey on table t2 depends on index t1_idx_a > HINT: Use DROP ... CASCADE to drop the dependent objects too.
Ugh, that sucks. I don't think it's a good argument for making the problem worse, though. What are we giving up by explicitly attaching the correct index? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
