Обсуждение: bug when dropping parent table

Hi,

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.

--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira wrote:
> Hi,
>
> 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?

/D

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.

[1] http://timbira.com/tmp/inh.png (sorry my pgsql is in pt_BR; the
message said 'relation "b" does not exist')


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

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.

Dave Page wrote:

> 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.
>
I have to agree with you. This is not for 1.8. Your idea of maitaining a
list of dependent objects is good but too expensive. Another idea is to
query the pg_depend to get all the dependencies (imitating the DROP ...
CASCADE code) before drop the target object. So we could scan the tree
for these dependencies and remove them too.


--
  Euler Taveira de Oliveira
  http://www.timbira.com/

Euler Taveira de Oliveira wrote:
> Dave Page wrote:
>
>> 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.
>>
> I have to agree with you. This is not for 1.8. Your idea of maitaining a
> list of dependent objects is good but too expensive. Another idea is to
> query the pg_depend to get all the dependencies (imitating the DROP ...
> CASCADE code) before drop the target object. So we could scan the tree
> for these dependencies and remove them too.

That sounds like a fine idea :-). I'll give it some thought.

/D