Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
От | Michael Paquier |
---|---|
Тема | Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert |
Дата | |
Msg-id | Zn9SDY0r9fLTqqDO@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
|
Список | pgsql-bugs |
On Fri, Jun 28, 2024 at 01:27:17PM +0200, Alvaro Herrera wrote: > I guess you could also fix this by adding a PK constraint to the parent > table, so that the situation is consistent in the other direction. Yes, I've also considered this option when thinking about this thread, but forcing a constraint creation up to the parent felt non-intuitive to me as we force creation of catalog entries on the children based on the state of the parent for basically everything else. So introducing a new path where we would do the reverse is a recipe for more complex code in tablecmds.c, which I'd rather avoid. > Here's a proposed patch for master only. It turns all three situations > being reported into ereport(ERROR); in one case I have an XXX comment, > because we have an alternative when attaching a partition that already > has a PK to a partitioned table that has a non-PK index: just create a > separate index in the partition. But that would cause slowness, which > is probably undesirable. I'm inclined to just remove the XXX comment, > but if anyone has other thoughts, they are welcome. An error sounds saner here in the long term. Tests for all of the code paths involved, perhaps? ;) -- Michael
Вложения
В списке pgsql-bugs по дате отправления: