Re: [HACKERS] Proposal: Local indexes for partitioned table
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Proposal: Local indexes for partitioned table |
Дата | |
Msg-id | CA+TgmoYuawysUZQ_JcpcWqp46SJnUSxW-h2p4Ea42WewHoMHwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal: Local indexes for partitioned table (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Proposal: Local indexes for partitioned table
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: