Euler Taveira de Oliveira wrote:
> Dave Page wrote:
>
>>> I saw I bug when dropping (Edit > Drop Cascaded) a table that has
>>> childs. I couldn't provide a patch, sorry. I only tested it on SVN code.
>>>
>> You mean a table thats a parent in an inheritance tree? What was the error?
>>
> [1] shows the problem. The problem is not in the DROP command; it's in
> the presentation. The function dropSingleObject() in frm/events.cpp
> tries to guess if it'll select the top or bottom object. Indeed it
> didn't consider that the top/bottom object was dropped too.
Yeah, I see - this relates to the improvements that Erwin and I have
been working on recently and falls into the category of 'things it's not
practical to fix right now' :-(
The problem we have with the treeview is that there is little in the way
of dependency tracking between objects, so when you DROP...CASCADE the
child table, the code doesn't remove the parent table from the tree...
> [1] http://timbira.com/tmp/inh.png (sorry my pgsql is in pt_BR; the
> message said 'relation "b" does not exist')
... and this then occurs when you try to drop it because it really has
gone despite what the treeview says.
I'm beginning to think that we need to try to maintain a list of
dependent objects within each object (perhaps by OID), and when we drop
or alter anything, we scan the tree for dependencies and refresh as
appropriate. I'm worried that could be expensive, but at least it should
be possible now that the refresh function is able to retain the node
state. This isn't a project for 1.8 though.
Thanks, Dave.
