On Tue, Dec 5, 2017 at 3:53 PM, David Rowley
<david.rowley@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
